Hmmm. OK.
This is a bad idea. My guess is the author will not be able to call this thing "Python", and for good reason.
Should it exist? Sure. Why not? The nature of FOSS is that anyone can tinker with it and make it into whatever they dream. Go for it! Just don't call it Python.
I use both 2.7 and 3.x. No drama. New projects go through a "Do we see any issues with 3.x?" phase where we try to list libraries we'll need and check for support. Not that difficult.
I absolutely understand companies/people holding on to 2.7 for dear life. Converting a non-trivial working code-base would be costly and very difficult to debug if that code base doesn't have extensive test coverage (probably true of most). It would also be utterly irresponsible in most business cases.
Most businesses don't have software developers sitting around doing nothing. Revenue comes from existing products and new features along with bug fixing. No customer of a software product will pay one dime for a company devoting a year to port their entire code-base to 3.x. Can you visualize that announcement?
"We stopped delivering new features and fixing bugs a year ago. Instead we ported our entire product to Python 3.x. Today, a year later, we give you exactly what you were using a year ago. Enjoy!"
Yeah. Exactly. The huge sucking sound you'll hear is that of customers leaving the company throughout an entire year of nothingness. In a dynamic free market competitors would eat you alive as you stop delivering features and fixes while they zoom right past you with a better offering to your customers.
That said, sticking to 2.7 for the long haul --say, ten years from now-- will create the Python equivalent of old COBOL code still running in deep dark places within financial institutions. It will create codebases nobody wants to look at or touch. It will create codebases that will be anywhere from hard to impossible to support as libraries will surely evolve to support the 3.x and, eventually, 4.x branch.
It is perfectly sensible for a company to, given today's realities, stick to 2.7. This is almost exactly the problem described in "The Innovator's Dilemma". Good management means focusing on delivering what your current customers are buying and want to buy. Unless they are clamoring for your product to use 3.x it could actually be really bad management to make the switch.
The only way to do it correctly would be to hire a full parallel team of programmers to port the codebase while mirroring every single new feature and bug fix implemented as customer's needs are met. At some future point the two branches would achieve parity in function and reliability. This parity would allow seamlessly switching to the new codebase without damaging customer relationships. Of course, this would cost a ton of money for a non-trivial product and, at the end of the process, the company would probably have to fire one of the two teams. Pretty messy and costly in more than just financial terms, isn't it?
I am not advocating either approach. Just saying I understand this from both engineering and business perspectives. People pushing others to just switch are doing so from a frame of reference devoid of any understanding of the realities of business. Most businesses are not about the technology, they are about what problem you solve for your customer. They don't care about "the geek stuff" behind the curtains. And rightly so.
Live long and prosper.