I agree that we should always try very hard not to break anything in point releases.  But I think it is fair to say that this is an unusual case.  Looking at the commit logs (and Tarek can correct me if I misread them), it appears the change that, among other things, moved customize_compiler was committed on 2010-01-23, in time for 2.7alpha3.  The language summit decision followed soon thereafter and the faulty partial revert happened on 2010-03-05, in time for 2.7alpha4.  So, if the revert had been completed as intended, the moved module should have only been in the wild for a little over a month.  Clearly you had a vested interest in making the change to your code base but it seems unlikely that anyone else would have gone to the trouble of changing their code since existing (2.6) code would have only been broken for that one small alpha window, 2.7 alpha3.  And considering that customize_compiler is probably not used by all that many packages to begin with it, I would think it is not unlikely that you *are* the only ones affected by it.

Nevertheless, what are the alternatives?  We could add a wrapper function into distutils.ccompiler that just calls the distutils.sysconfig version.  Here's a patch that attempts to do so. That should fix that breakage for the eGenix packages.  It would be great if you could test it.

It's up to the 2.7 release manager to decide what action to take, i.e. whether the patch is needed and, if so, how quickly to schedule a new release.  As a practical matter, regardless of whether the patch is applied in Python or not, I would assume that a faster solution for your end users would be to ship a version of the eGenix packages that reverts the changes(s) there.  By the way, it looks like you'll need to eventually do that anyway since the code in mxSetup.py incorrectly assumes that the corresponding changes were also made to Python 3.2.