As soon as you realize that changing rasterization strategies alters the bounding box of character textures, and that a lot of UI positions are hardcoded, it makes sense.
Hardcoding UI positions is one of those "you're doing it wrong" sorts of things. At my day job, both the UX/UI folks and the localization folks would have a conniption if I built something with hardcoded UI positions/sizes, or that broke if the size of a string changed. As soon as you have a user with a hidpi display your application is going to look like garbage. As soon as you want to try to support non-English languages all your hardcoded UI work goes out the window.
> As soon as you have a user with a hidpi display your application is going to look like garbage.
And this is what my yearly-or-so foray into Windows shows up - most apps look like garbage. The handling of displays with different DPIs connected to one machine is even worse. This has even been a solved problem _on Linux_ for quite some time.
This likely isn't much of an issue for the operating systems themselves, as they are well globalized and (in my experiences with Windows) adapt fine to RTL and CJK scripts.
Third-party apps, on the other hand, do seem rife with clipped text, even in English at nonstandard DPIs.
Edit: Ah, this was already said by the existing sibling comment.
I believe Windows's approach is localisation not globalisation. Many programmes runs properly only in designed locales, not that programmes run well in any locale.
Chinese/Korean rendered incorrectly on English UI because system hardcoded a font fallback, which put Japanese font first, regardless of how languages are ordered in the Settings. This is largely true for traditional Win32 programmes, like Chrome, Edge, Explorer.exe, etc. However UWP apps using the new UI framework (like Unigram, Intel Command Centre etc) behave correctly if setting Chinese/Korean as secondary language.
It's different on macOS or iOS however, if you set a system locale order as 1. English, 2. Chinese, then Chinese content will render correctly with correct Chinese system font PingFang.
Another issue that is also very important is that Chinese (Simplified or Traditional), Korean and Japanese share amount of the same characters but written differently. That means system must render the glyph in correct variant, like in the example of Source Han Sans
> changing rasterization strategies alters the bounding box of character textures
This is big problem on Windows, where the heavy-handed hinting means actual font size doesn't even come close to being linearly related to requested font size. So you can't even make the simple assumptions such as that the same UI layout will work if you render everything at 2x for a high DPI screen.