> You never run a command twice unless you explicitly reinitialize it
> (which then resets .compiler to None and then fetches the command line
> option again), so the above is not a problem.

In practice yes that's true.

> The "compiler" option on the build_ext and config commands
> are not really needed. Their .finalize_options() methods could
> easily pull in the build option value and place it into
> an .compiler_type attribute which then gets used as basis for
> creating the .compiler instance, or even better refactor the
> various commands to use a central method on the build
> command object to create a compiler object and avoid all
> the copy&paste code for this.
> Furthermore, the .finalize_options() methods could detect whether
> a per-command option as used and deprecate this use instead,
> redirecting to the build command option.

Having a single location sounds like the best idea with the current
behavior, reachable from cmd.get_compiler_object() like you did.

Now the question is, in practice, could someone force a
different compiler in build_ext for instance, or with a different
configuration than in build_clib ?

I don't see a use case in practice for that, but if so, we would need to
keep a different compiler instance per command.