From issue #19553:

8. "make install" is a superset of "make altinstall" and one would expect the results of (a) "make install" to be the same as (b) "make altinstall && make install".  However (b) results in "python -m ensurepip --altinstall --upgrade && python -m ensurepip --upgrade" which results in no unversioned pip files being installed as the second call to pip does nothing:

Requirement already up-to-date: setuptools in /py/dev/3x/root/uxd/lib/python3.4/site-packages
Requirement already up-to-date: pip in /py/dev/3x/root/uxd/lib/python3.4/site-packages

We may need some magic on the pip side when ENSUREPIP_OPTIONS is set to make this behave consistently.

Making this happen is a non trivial change to pip. Is this *required* for PEP453?

The problem is the pip dependency is already being seen as fulfilled so it's not reinstalling pip again with the new options picked. Likely the actual answer is a command in pip to regenerate the scripts but that will require some engineering.

Fixing in pip 1.6/CPython 3.4.1 would be fine by me - that's why I only created it as "high" rather than "release blocker"

Ping.  Also this will be presumably be an issue for the approved 2.7.x backport of ensurepip.

No change for 3.x (unless something changed on the pip side that I'm not
aware of).

For 2.7, the Makefile changes, at least for the install and altinstall
targets, were deliberately excluded from the backport PEP.

So here's a thought:

pip does have a CLI flag --force-reinstall which will uninstall and then reinstall whatever is being installed. If we modified things so that ensurepip supported this flag (or always used it with --upgrade) then it would fix this issue. The downside here is that only works with --upgrade.