For the record:
https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states:
> MSVCRT […] Works out of the box on every Microsoft Windows versions.
This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2.
The original Windows 95, with or without the only service pack released for
it (SP1, because OSR 2 was not released as a service pack, only as an "OEM
service release" for new computers), shipped only the even older CRTDLL.DLL
(which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had to
be installed through a redistributable (which was included with many
applications including Microsoft Office, but it was not part of the
operating system).
But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version
numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the
box, UCRT is not. Is it really a good default to depend on a runtime library
that is only included in Windows ≥ 10?
This proposal doesn't change the default. Although we can discuss whether deprecating msvcrt support in Fedora-MinGW would make sense today.
Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in the future.
Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets.
But there is at least one user that may legitimately want to keep a msvcrt 32bit target: mingw-wine-gecko.