Make the 2 vs 3 language decision be module-specific with a single Python executable supporting both languages, allowing you to freely mix Python 2 and 3 files and libraries and thus not splitting the ecosystem.
I believe that would have been much more expensive to develop, and the Python dev team didn't have the resources for it.
The easiest things can be done by automatic translation, like 2to3.
The remaining parts get increasingly difficult, because Python 2 objects have to know how they are interpreted in Python 3, and vice versa.
A simper step would be to write an AST transformer to instrument Python 2 code and identify the non-Python 3-compatible uses of, for example, keys() and values(). That's almost as hard as writing a Python 3 implementation in Python 2, and I couldn't convince myself that it made financial sense given that it would still miss a lot of corner cases.
They did that where possible (from __future__ imports, forwards compatibility changes to a bunch of internal apis (the C extension api, as well as stuff like the code object)), but there's not a cross-compatible way to handle the unicode/bytes change. Python2 has, essentially, a single text-bytes str type. Python3 has different ones. You can't cross that boundary from 2 to 3, because the runtime has no way to know which of text or bytes a given str is.
What you can do is use libraries like six to make code run just fine in both versions, and six-ify on a per file basis. This works pretty well.
The easiest things can be done by automatic translation, like 2to3.
The remaining parts get increasingly difficult, because Python 2 objects have to know how they are interpreted in Python 3, and vice versa.
A simper step would be to write an AST transformer to instrument Python 2 code and identify the non-Python 3-compatible uses of, for example, keys() and values(). That's almost as hard as writing a Python 3 implementation in Python 2, and I couldn't convince myself that it made financial sense given that it would still miss a lot of corner cases.