All commit authors signed the Contributor License Agreement.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

More generally, could it cause issues with platforms that are configured with --with-platlibdir=lib64? On OpenSUSE I need to explicitly specify this when doing ./configure, otherwise Python won't be correctly installed.

It is also not necessary anymore because venv now creates lib paths in venv directory based on sysconfig.

Is there a possibility that this could somehow conflict with legacy venvs? or with some weird sysconfig? If this is causing issues on platforms without symlink support why not just checking if that platform supports symlinks and, if not, do nothing?

could it cause issues with platforms that are configured with --with-platlibdir=lib64?

The difference on these platforms is that platlib and purelib modules will be installed into separated directory (lib64/ and lib/) as defined in posix_venv installation scheme. This is also virtualenv's current behavior.

Is there a possibility that this could somehow conflict with legacy venvs?

I think this only affects venv creation. Legacy venvs should still be able to run.

If this is causing issues on platforms without symlink support why not just checking if that platform supports symlinks and, if not, do nothing?

In my understanding this symlink is not needed in anyway. Other paths created by venv are all looked up from venv scheme sysconfig except this symlink which is hard-coded and created even unnecessary. So I remove it for consistency.