> The first sentence meant that claiming the command-line executable name python for Python 3 is hostile to letting an execution environment for Python 3 and an execution environment for Python 2 co-exist going forward without having to modify existing programs that assume that python is for Python 2 and python3 is for Python 3.

Yes, but I don't believe I've seen any (real) suggestions to change PEP 394.

> There's Tauthon.

Which I claim is actively bad for python's ecosystem in the long term. It shouldn't be supported by any organization that wants what is best for Python.

> There are probably others. Also, there's the need to keep the server side of pip up and running for these to work.

That works just fine without any help. pypi continues to support python2 tags and wheels, and I doubt that'll change anytime soon.

> There's Active State's long-term support for Python 2. There's presumably Red Hat's long-term for Python 2.

So the entire reasonable bit here is that the PSF should provide something to help various enterprise companies manage backporting security patches. Which, like, I'm not sure what infrastructure is actually needed for that. They already make security patches public. Unless you're suggesting that LTS enterprise support offerings should co-ordinate additional feature work on python 2, which is both unusual and again I claim actively harmful to the ecosystem.