And we don't actually mind all that much if applications don't migrate in the near term - Python 2 will have commercial support available well past 2020. (The developers of *those applications* might mind, though,
The group we *do* really care about supporting is authors of existing Python *libraries*, and "2in3" and "3in2" approaches don't really help them at all, since library and framework authors with users on both Python 2 and Python 3 will likely face demand to support both versions natively anyway.
Lets assume for the moment that the 'we don't really care about the 60% of python developers blocked from moving to python 3 by depencies' was not really what you meant.
I am going to assume that what you really meant was 'I do not think helping these people directly is the best solution'. And this attitude is based around the fear that if the developers can move to python 3 before the libraries all support python 3, then that will remove pressure from the libraries to support python 3.
This fear i can understand. But I suggest some real world experience shows this approach is actually not assisting either group. It is certainly not assisting the developers wishing to move to python 3, but it is also making life hard for the "people we do really care about"
So not supporting a "2in3" solution forces programmers to with python2 dependencies to hold off moving to python3 until their dependencies migrate, but hopefully with sound motives.
Now take a typical dependency. Web2py. Speak to them on migration and they will telly you 'none of our users have moved to python 3'. So the users are held back from moving by the dependencies, and the dependencies are held back by the users.
I would suggest that making it easier to support both python2 and ptyhon3 from a library is simply reducing what it a painful thing. I would suggest that allowing all the end users to migrate to python3 as soon as possible is a far more attractive solution.