Any update on this? Anything preventing this from being merged or is it just awaiting approval?

This PR is stale because it has been open for 30 days with no activity.

The wslpath prong keys on the kernel string, so it also fires for native Linux venvs created with python3 -m venv inside WSL, rewriting an already-POSIX VIRTUAL_ENV. The discriminator should be the path, not the shell.

virtualenv handles this without any WSL detection: it derives VIRTUAL_ENV from the activate script's own location when the recorded path doesn't resolve, and only cygpaths for the Cygwin family: activate.sh L62-77. Adopting that here — fall back to a script-relative realpath when __VENV_DIR__ isn't a directory — fixes the /mnt/...-mounted Windows venv without touching native Linux venvs and without depending on wslpath being present.

One detail: virtualenv's fallback uses ${BASH_SOURCE[0]}, which is bash-specific — and virtualenv has no separate zsh activator either, so zsh sources the same bash script where BASH_SOURCE isn't set. The script-relative fallback is effectively bash-only in both tools, so adopting it in CPython's activate (documented for bash and zsh) would want a shell-portable self-location rather than BASH_SOURCE alone.

Separately, this only sets VIRTUAL_ENV/PATH; the venv's Scripts/* shebangs and pyvenv.cfg home stay Windows-absolute, so console scripts still won't run from WSL bash. Worth noting in the issue/NEWS so the conversion isn't oversold.