Uhm, do you understand what "focused exclusively" and "no support for earlier" mean and how they differ from merely adding "Py 3 support" to a legacy product?
Any resources (time, attention, research, answering user questions, design simplicity, ...) that are expended in an effort to support pre-3.4 versions and users are resources that could be turned instead to the challenge of making the 3.4+ product even better.
With this approach, he could potentially, gradually, change the market's mindset from "mod_python is dead, use mod_wsgi" to "if you're still stuck with Py2, you'll have to use mod_wsgi, but if you are starting a new project, you should go with mod_python."
Priority should be given to making mod_python compile for Apache httpd 2.4, so applications stuck on httpd 2.2/Python 2 can be migrated. This is likely to generate the strongest initial interest. Dropping support for Python 2 would interfere, especially where libraries are used that haven't been updated to work with Python 3.
All projects have finite resources that they allocate as they see fit. You say that priority should be given to legacy upgraders for the sake of "strongest initial interest." That may well be his preference, too, and if so, the costs of doing so will be debited from available resources.
It is, of course, his choice, but I'm suggesting that there is an alternative where all available resources are focused on the future, benefiting new projects at the expense of whatever remains of the legacy, going for strongest ultimate interest even at the possibility that it might not produce the strongest initial interest, and attempting to own the mindshare of "best system for new Python projects" by positioning itself exclusively as that, not positioning new Python project support a recent add-on to an old, legacy technology.
It's a matter of choosing market, positioning, and resource allocation, and I'm pointing out how, with a certain choice, the market perception that "mod_python is dead" doesn't have to be a problem and could even have advantages.
Any resources (time, attention, research, answering user questions, design simplicity, ...) that are expended in an effort to support pre-3.4 versions and users are resources that could be turned instead to the challenge of making the 3.4+ product even better.
With this approach, he could potentially, gradually, change the market's mindset from "mod_python is dead, use mod_wsgi" to "if you're still stuck with Py2, you'll have to use mod_wsgi, but if you are starting a new project, you should go with mod_python."