
"... encouraged in __3.x guidelines__ to ...": I presume although I've not found them yet that there is some kind of document for developers titled something like, "how to migrate your Python code from 2.x to 3.x". That document would be a logical place for advice and consideration of the tradeoffs of jumping to 3.x, maintaining two synced versions using 2to3 or 3to2, and the risks of keeping two independent releases. Identifying best practices would help them make good choices for the community.
I don't think any of the core committers is qualified to write such a document. Instead, it would have to be written by people who *actually* ported a project from 2 to 3 in some form. That is not to say that such a document couldn't be part of the 3k release, or shouldn't be reviewed by core committers. [Also, it might turn out that some of the core committers writes such a document, with the theoretical background of what *could* work for projects. That would be a lot like all those books giving advise written by people who never followed their own advise because they never had a chance to].
So we don't have an actual success story of a dual-version distribution, even as a prototype, using 2to3 within a distutils package? I would not encourage a practice without at least one such example.
We don't have any success story for Python 3, period. Nobody has ever attempted to run a significant code base in Python 3, other than the test suite, AFAIK.
It always worked fine for me, so I see no reason to fix it in the first place.
Pardon my lack of knowledge of your background; when you say it always worked fine for you, are you referring to personal experiences using it to _install_ software or to experiences as a packager in actually distributing complex collections of modules on different platforms?
I've been maintaining a larger project (PyXML) for several years, and have written/maintained a few smaller projects (iconv, partial, python-fam), which all used distutils. I have also extended distutils in the core, with the upload and bdist_msi commands. And then there is the experience with installing distutils-based packages, which is usually pleasant (although I prefer to use the Debian package where available) Regards, Martin