Hi Ian,
The only workable workflow I've seen people propose for maintaining a single codebase with compatibility across both 2 and 3 is to use such tricks, with aliases to suppress some 2to3 updates when they are inappropriate, so that you can run 2to3 on install and have a single canonical Python 2 source. Python 2.7 won't help much (even though it is trying) as the introduction of non-ambiguous constructions like b"" aren't compatible with previous versions of Python and so can't be used in many libraries (support at least back to Python 2.5 is the norm for most libraries, I think).
Also, running 2to3 on installation is kind of annoying, as you get source that isn't itself the canonical source, so to fix bugs you have to look at the installed source and trace it back to the bug in the original source.
I suspect a reasonable workflow might be possible with hg and maybe patch queues, but I don't feel familiar enough with those tools to map that out.
That's why I am saying that we need a Code-Repository: section in PEP-345 Metadata. Let package developers keep two branches in SCM. One for 2.x and one for 3.x Let them backport features from their 3.x development series to their 2.x code base. In exactly the same way that it is done in so many other developments today. Keeping multiple branches of code is a very common thing these days. And there are tools in the outside world (bzr,svn,mercurial) that allow us to do it very easily. Let's have that support in python; it will make life easier. David