> Well my first feeling was that U+202F should work all the time, but I > found cases where this is not always the case. So this must be bugs in > those renderers. >
I think we can attribute these bugs to the fact that this character is insufficiently known, and not even accessible in most input tools... including the Windows "Charmap" where it is not even listed with other spaces or punctuations, except if we display the FULL list of characters supported by a selected font that maps it (many fonts don't map it) and the "Unicode" encoding. Windows charmap is so outdated (and has many inconsistancies in its proposed grouping, look for example at the groups proposed for Greek, they are complete non-sense, with duplicate subranges, but groups made completely arbitrarily, making this basic tool really difficult to use). And beside that, all the input methods proposed in Windows still don't offer it (this is also true on other platforms). So finally there are not enough text to render with it, and renderers are not fixed to render it correctly, developers think there's no emergency and that this bug is minor, it can stay for years without ever being corrected (just like with the old "Charmap" on Windows) even if such bug or omission was signaled repeatedly. This finally tends to perpetuate the old bad practices (and this is what happened with ASCII speading everywhere even in scopes where it should not have been used at all and certainly not selected as the only viable alternative, the same is seen today with the choice of languages/locales, where everything that is not English is minored as non-important for users).