The build_ext command cannot be run twice, because the first time, the
"compiler" option may be set to "unix" for example, or left to None, and
then is transformed into a compiler object. That's the bug.

If you call it again, it'll break because the new_compiler() function
will receive self.compiler, which is supposed to be a string not a
compiler object.

"compiler" is described as the "compiler type" in the options list of
build_ext and should receive a string value.

So what's broken is the fact that third-party code is using "compiler" 
as a compiler object attribute for years, because the command was
creating the compiler object on the compiler option, rather than using
its own attribute for that. And from an architectural point of view, if
you have to tweak the compiler options by tweaking them direclty, it
means that the build_ext command did a bad job with in the options
it provides.

For the cross-version incompatibility you are mentioning, it means that
your code is working with "compiler" as a string option, then continue
to work with it as a compiler object right after the command is run.
But either way, there will be an incompatibility starting at 3.3 because
we are going from the state "compiler is a string and also a compiler
object, depending on when you use it" to "compiler is a only string option"

This is an inconsistent behavior I am fixing here. While the code may be
more complex with the descriptor, this will eventually go away in 3.3
(and 2.8 if it exists).

What is the other solution you where thinking about ? adding a
compiler_type option and keep the compiler option woud introduce more
incompatibilities since "compiler" is used to configure build_ext by
many code out there, while tweaking the compiler object itself is an
advanced usage done by less people, which may do the same thing in an
easy way by using another attribute.