As I noted elsewhere, it might not be such a big deal for JavaScript clients since JS syntax/APIs that work on plain objects tend to also work on arrays, but in other languages this obviously isn't the case. Since it's kinda rare for an entity not to have a single label/description/alias/claim/sitelink, and this behaviour doesn't seem to be documented anywhere, it's not very likely that the person writing the client will think to account for this until it's too late.

Breaking change: a change to an API or data format that violates guarantees given or widely assumed before. Breaking changes include removal of API functions, parameters, or data fields and changes to the interpretation or format of parameters or data fields.

This is one of the weirdest cases I've done. PHP doesn't distinguish between array and associative arrays when they are empty and there is no way to send this information around in php while in python they are completely different objects (lists and dictionaries). The reason that wbgetentity API module and the dumpers return {} instead of [] is because these containers are not passed around empty, they contain hidden elements that you can see when you change the formatting to xml (and for whatever reason, mediawiki needs to support xml output forever and beyond) but when they are turned to json, the hidden elements get stripped away but json knows it's a associative array.

What I did was that I just told ResultBuilder for Special:EntityData to add metadata (while they get removed in final output anyway). That would fix the issue we are dealing now. It's behind a config variable.

The current stable interface policy seems to be specific to Wikidata only –

This Stable Interface Policy defines which guarantees are and are not given by the Wikidata development team regarding the stability of data formats and APIs provided by Wikibaseas deployed on www.wikidata.org.

(emphasis added) – so for now let’s just deploy this bugfix to Commons at the same time, assuming that if anyone is already using Commons’ Special:EntityData, they’ll do it with the same code that they also use for Wikidata’s Special:EntityData, and which is prepared for the fixed output format. The future of the stable interface policy with regard to Commons will be discussed elsewhere, I am assured.