Martin> c) ask for consent in advance to making a potentially-breaking Martin> change.
Doesn't that potentially extend the release time for an enhanced distutils across multiple Python releases?
Yes, but your alternative doesn't "scale" over time. At some point, modifying setuptools will not be acceptable anymore because of the risk of breaking packages that rely on intimate details of setuptools.
What are we going to do then? The "natural" expansion is this: Invent a new library, say, setuplib, which sits on top of setuptools, and then (copying) "setuplib can be designed and implemented to suit the needs of its constituency while setuptools remains available and compatible for those people using it." People will just have to replace
from setuptools import setup
from setuplib import setup
The new setuplib will be completely transparent: if you don't explicitly use it, nothing will change.
Sarcasm aside, this isn't a good approach to software versioning, IMO.