I'm not particularly happy with the statement that "However, the latter is out of scope here since the entry-point launchers are in distlib."

If Python is changing the semantics of __PYVENV_LAUNCHER__ in such a way that it breaks 3rd party code, it seems to me that this is a bug, which should be addressed by reverting or fixing the change so that the 3rd party code does not need to change. Either that, or the change is publicised as a backward compatibility break, so that tools are given a chance to update.

Having said all of that, I appreciate that __PYVENV_LAUNCHER__ is not exactly a public API, so there should be some leeway here. But I think that whatever solution we propose here needs to address how we manage the change required of third parties.

I still need to fully read and understand this discussion - I've not really followed any of the work around publishing Python as a Store application, taking the view that I won't use it myself, so "it won't affect me". But now I'm starting to worry about whether I'll see pip bug reports being filed because pip's installing things in the wrong places ("Similarly, pip.exe for an installed Python 3.7 will mistakenly install into the virtual environment.") If that sort of thing does happen, it harms our credibility and we need to be able to clearky explain what's going on, and how to fix it.

Can I clarify 2 things:

1. Is there a possibility that 3rd party applications like pip could see bugs with Python 3.7.2?
2. Is there a workaround or fix for those issues, and how are we making sure the relevant 3rd parties know what to do?

(Again, apologies if I've misunderstood something here - there's quite a lot of technical detail that I haven't had time to understand yet).