This specific approach is discussed in the PEP.
I would appreciate it if we don’t end up going into a cyclical debate about the proposal at this point though, especially about something already discussed at length here and over the years. The reason this PEP is long is because it discusses a large matrix of effects of the design choices and picks a design with the most sensible tradeoffs that aren’t too painful outside of one specific workflow that was deemed problematic.
As far as I can tell, we’ve discussed and looked at all the possible solutions in the years leading up to this PEP, especially the ones that people who seemingly haven’t read the PEP have proposed as the “obvious” solutions after the changes described in this PEP rolled out affecting their workflows that relied on mangling system packages due to not using virtual environments.
To be clear, I’m not singling out @Ark-kun here – many people on the Internet have proclaimed that a system Python/separated distro scheme/magic pixie dust is the obvious technical solution with no tradeoffs; other than of course the complexity of actually implementing it on shoe-string resourcing that most of these foundational pieces of open source software operate on, as well as the amount of coordination it’d require by oh-so-many people aside from the aspects that the PEP already covers. They aren’t wrong that those solve the problem of pip install failing in a manner that requires additional user action, but we’re not locked out of them with this proposal either.