I also see this behavior at the current head of the 3.11 branch: 4fc042f but not at the current head of the main branch (ccab67b), where only pip3 and pip3.12 are installed.

Hmm, actually, a correction -- my main branch was behind. At tag v3.12.0a1 (commit 4ae1a0e), building Python installs pip3, pip3.10, and pip3.12.

Bisecting suggests that the extra pip3.10 was introduced with the commits that upgrade setuptools and pip:
c954335 (on 3.11 branch)
9da5215 (on main branch)

Looking at the contents of Lib/ensurepip/_bundled/pip-22.3-py3-none-any.whl in 9da5215 (by adding a .zip extension), pip22.3.dist-info/entry_points.txt says:

[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
pip3.10 = pip._internal.cli.main:main

Looks like a pip bug. pip contains logic to specially fix pipX.Y (and easy_install-X.Y) entry points to correctly match the Python version, but that logic only accounts for single-digit version numbers and doesn’t work with 3.10 upwards. We didn’t notice this earlier because pip bundled in 3.10 was built against 3.10 and no dynamic replacement was needed, but pip 22.3 (bundled in 3.11.0) was built against 3.10, not 3.11, exposing the bug.

https://github.com/pypa/pip/blob/ff207cff2aeea05f13a246a99f24e6944492b18e/src/pip/_internal/operations/install/wheel.py#L328

Fix submitted to pypa/pip#11547

Gentle suggestion:

Although the problem's roots are in pip, given that the problem is the way the pip wheel was built (with Python3.10), could we patch the wheel in the repo to fix this problem, so that we don't have to wait for a new pip release?

I just verified locally that removing the pip3.10 entry point from pip-22.3-py3-none-any.whl seems to solve the problem on my machine:

unzip Lib/ensurepip/_bundled/pip-22.3-py3-none-any.whl pip-22.3.dist-info/entry_points.txt
sed -i '/pip3\.10/d' pip-22.3.dist-info/entry_points.txt
zip Lib/ensurepip/_bundled/pip-22.3-py3-none-any.whl pip-22.3.dist-info/entry_points.txt

It’s plausible. The RECORD file should also be patched for the hash to match; pip does not verify the value, but it’s better for correctness.

It seems this problem also affects the Windows install binaries.

I installed 3.11 using python-3.11.0-amd64.exe and the following pip binaries are present:

• Scripts\pip.exe
• Scripts\pip3.exe
• Scripts\pip3.10.exe
• Scripts\pip3.11.exe