venv.EnvBuilder creates inconsistent venv depending on the name of the Python executable

Bug report

Bug description:

Given the below create-venv.py script and several Python 3 installed in the classpath:

import sys
import venv


if __name__ == "__main__":
    venv.EnvBuilder().create(sys.argv[1])

Let’s create various venvs:

for VERSION in 3.9 3.11 3.12; do
  python$VERSION create-venv.py $VERSION-venv
  for EXEC in python python3 python$VERSION; do
    $VERSION-venv/bin/$EXEC create-venv.py $VERSION-$EXEC-venv
  done
done

And now, let’s check them:

for PYTHON in *-venv/bin/python; do
  echo "$PYTHON: $($PYTHON --version)"
done

The above loop outputs:

3.11-python3.11-venv/bin/python: Python 3.11.7
3.11-python3-venv/bin/python: Python 3.9.14
3.11-python-venv/bin/python: Python 3.9.14
3.11-venv/bin/python: Python 3.11.7
3.12-python3.12-venv/bin/python: Python 3.12.1
3.12-python3-venv/bin/python: Python 3.9.14
3.12-python-venv/bin/python: Python 3.9.14
3.12-venv/bin/python: Python 3.12.1
3.9-python3.9-venv/bin/python: Python 3.9.14
3.9-python3-venv/bin/python: Python 3.9.14
3.9-python-venv/bin/python: Python 3.9.14
3.9-venv/bin/python: Python 3.9.14

As the reader can see, Python venv’s created by python or python3 executable of a Python venv will not use the Python of this venv, and instead will use the system’s default Python (3.9 in my case).

CPython versions tested on:

3.11, 3.12

Operating systems tested on:

Oracle Linux 9 and 10

Start with the supplied create-venv.py script and the venv.EnvBuilder entry point, then run the shell loop with multiple Python executable names to reproduce the inconsistent interpreter selection. Trace how the executable used to invoke EnvBuilder is recorded and used when creating each environment; done means python, python3, and versioned executables inside a venv consistently create environments using that venv's interpreter.