>> If there is no interest in having a (community-supported, semi-
>> official) GCC-built Python on Windows, I'm sure something else
>> can also be worked out, which would include stripping the current
>> dinosaur -mno-cygwin code which is what this bug was originally
>> all about.
>
> The issue is about building Python *extensions* with gcc, not about
> building Python itself - that's not a supported approach at all
> (MSYS2 does it, but the patches used aren't going to be integrated
> in core Python).

Let's say you have the official, upstream W32 CPython, built with MSVC and linking with, say, msvcr90.dll
You build, say, libarchive-1.dll with MinGW-w64, because that's what you use to build stuff. Because it's MinGW-w64, libarchive-1.dll links to msvcrt.dll.
Then you want to build, say, pyarchive extension for your Python and you do that with MinGW-w64, because that's what you use to build stuff. Because it's msvcrt.dll, libpyarchive.pyd link to msvcrt.dll.
Then you run Python code that takes, say, sys.stdout file object and passes it to pyarchive. Python file object is backed by msvcr90 file descriptor. pyarchive expects a file object backed by msvcrt file descriptor. Boom.

Only three ways of avoiding this:
1) Use MSVC for everything. This is what upstream CPython does.
2) Use MinGW-w64 for everything (including CPython itself). This is what MSYS2 does.
3) Use MSVC for CPython and MinGW-w64 for the rest and somehow ensure that FDs are converted when passing the CRT barrier. And stat structs as well. And everything else that differs. This is a path of frustration that leads nowhere and does not seem sustainable to me.

This is why the discussion keeps coming back to building Python with MinGW-w64. This is why Universal CRT can be a solution (the absence of CRT incompatibility would resolve a lot of issues; the rest is manageable - remember MinGW-w64 has to use the same CRT/W32API DLLs that MSVC does, so binary compatibility is always achievable for anything with C interface).