> The feature freeze applies to all branches.  Even when 3.4 starts, the 
> same rule that has been repeatedly explained for two years will apply: 
> no new features in distutils.  Again, neither Tarek nor I are happy
> about that, but it was the decision taken by python-dev due to the big 
> number of setup.py scripts depending on undocumented behavior, bugs and 
> quirks.

then you use monkeypatching.  split the new functionality into
a separate module - ..../distutils/mingw.py - that is called by
a clear ONE LINE modification in distutils.py that CLEARLY cannot
have IN ANY WAY not one SINGLE effect on ANY OTHER python port.

that line would be something like:

    if sys.compiler == 'mingw32': import distutils.mingw

within that distutils.mingw it would monkey-patch distutils to
add itself into the distutils code.

the same technique could be used by ray to monkey-patch the
cygwin compiler by doing this:

distutils/specialportmaintainedbyray.py:

distutils.cygwincompiler.RE_VERSION = re.compile(b'[\D\s]*(\d+\.\d+(\.\d+)*)[\D\s]*$')

of course, for this to work, support for the ports are required
(identification of the ports) down at the sys.py and os.py level.
unless you expect these port maintainers to put in special 
monkeypatching into the c-code itself (which would of course be 
conditionally compiled and would in no way affect ANY other port of
python).

this would be perfectly reasonable.  the impact on other ports would
be zero.  consideration of the one line patch would take a few
minutes.

... and for those packages that depend on undocumented behaviour?
in the unlikely event that they ever get compiled for mingw32 or
ray's port, well, the person who compiled such a package would 
encounter an error, and would wonder why it was broken, and then
would get onto a mailing list and go "i have a problem, can anyone
help me".

chances are that the majority of packages would however compile
cleanly.

there's always a way.