Not at all. Mingw support is important for the scientific community, as I understand it, and I'm willing to help there if I can. That won't be at the cost of other areas I can contribute to, but I consider packaging as much my area of expertise as Windows - and mingw support covers both of those areas.

To give some background, I was involved in adding mingw support for the MSVC 2010 builds of Python, which involved working with the mingw project on getting -lmsvcr100 support added. That was a battle, and I fully expect universal CRT support to be even harder[1]. I do *not* expect to get involved in that, but as I said, I do want it (along with a single mingw distribution blessed by the Python mingw user community) as a prerequisite for a higher level of core support.

That's (IMO) a *very* high bar, and I don't expect it to be easy for the mingw-using community to achieve it. But if they do, then the amount of effort involves deserves some recognition, and for my part I am offering some of my time improving core Python support on that basis.

[1] For example, AIUI, with the universal CRT, even the header definitions change - e.g., FILE* is not based on an _iob symbol - so you have to know the target CRT at *compile* time, not just at link time. That's an additional level of complexity not present in previous CRT releases.