This, and I also strongly argue that compiler implementations should be untied from standard libraries, and this also applies to libc++/libstdc++. A compiler shipping its runtime is a bad idea that totally screws up compatibility (just look at how painful it is to use MINGW + C++ on Windows because it can't link with VS's C++ Runtime - I understand that MS headers are crap to parse, but with a bit of effort clang now does it fine), and ties them together and prevents reuse. In an ideal world shipping a runtime should be the OS's role, not the compiler's, and the compiler should make use of whatever the platform ships, instead of having N compilers shipping N different, incompatible libraries. The interface between the library and the compiler would then become a true language standard, instead of "library for compiler version X.Y.Z"
Stable ABIs are good, but the ability to break it and iterate/improve is even more so. GNU platforms are currently stuck with a shitty std::string implementation (32 bytes but only 15 bytes of SSO capacity) because breaking ABI means recompiling your entire Linux distro.
As he notes there, Windows does ship a C/C++ runtime, but you're not allowed to use that one - it is only for internal Windows stuff and only ever has to be compatible with whatever software comes with Windows. Any Windows update can make it binary-incompatible with a third-party program. User axjs notes in another top-level comment that a Google libc(++) will always just serve Google's products, including keeping bugs that a Google product relies on - somewhat similar to the Microsoft C/C++ runtime that comes with Windows, which you are strongly encouraged not to use.
That ship has sailed a long time ago, anything compiled with MinGW links against MSVCRT.DLL and did that from the beginning. Considering they had to backpedal changes in that DLL because it broke some program, as mentioned in the linked blog, i doubt this DLL will ever be removed as that will break thousands of applications that have come to rely on it.
Considering that it isn't the default and it is only available on Windows 10 (and that only since 2015) i think that it is very safe to say that for all intents and purposes "anything compiled with MinGW links against MSVCRT.DLL" is valid and will be for a long time.
Though even if MinGW switched to UCRT tomorrow, it would still leave a ton of executables since 1998 (or whenever it started using it) relying on MSVCRT.DLL (which AFAIK is included by default in Windows since Windows 98 so it has a slightly wider support range than UCRT :-P).
