Nan j'pense que dans ce cas c'est juste un standard de développement et de fiabilité qui sont faibles. C'est la norme, encore plus chez Apple d'ailleurs (chez Apple ils codent assez mal, mais ils testent à outrance puisque tous les employés sont obligés d'utiliser un iTruc comme appareil principal, résultat ils tombent dessus la plupart des trucs bizarres, mais c'est aussi pour ça que toute option non-par défaut, lorsque c'est possible, produit en général un écosystème inutilisable, tu sens que ça n'a juste pas été testé et encore moins pensé sur du concret).

Le truc c'est qu'il y a une grosse cassure entre le milieu des années 2000 et avant. Les ingés qui développaient "comme avant" ont en gros disparu et les nouveaux, qui ont tendance à être plus jeunes (et souvent avec moins de connaissance) ne sont pas capables de reprendre le code, donc ils font un truc tout nouveau tout chaud, avec son lot de nouveaux bugs, ou alors ils introduisent des bugs subtils dans une base de code existante, car ils ne comprennent pas tous les tenants et aboutissants. La faille est aussi dans le TDD (test driven development) qui est une bonne idée mais généralement se pète la gueule à mesure que le code évolue, car quand on ajoute ou change quelque chose, on ne peut pas déterminer quels seraient les tests à modifier ou ajouter, il faudrait littéralement revoir tous les tests. Du coup on laisse de plus en plus de "trous", on a une fausse impression de fiabilité car tous les tests passent. Dans ce cas probablement personne n'a pensé à ajouter des tests avec des espaces colorimétriques non-standard, car Android ne les supportait pas au début.