Following up on https://bugs.python.org/issue37369 as it was advised to open a new issue regarding case sensitivity.

I am on Windows 10 running Version 10.0.19041 Build 19041. I am experiencing the same problem in that issue when using venv on Powershell. 
The path to python.exe in the pip.exe generated by venv is all lowercase, which is the source of this error.
After activating the venv with Activate.ps1 and attempting to use pip, I get the following error, while activate.bat on cmd works fine:

Fatal error in launcher: Unable to create process using '"c:\users\chris\code\project\myenv\scripts\python.exe"  "C:\Users\chris\code\project\myenv\Scripts\pip.exe" ': The system cannot find the file specified.


Full steps to reproduce:
  1. Install Python 3.8.6 from python.org (ticking add to PATH option in installer)
  2. Open Powershell (via both native Powershell app or the new Windows Terminal) and verify that `python` is bound to the correct Version
  3. Run `python -m venv myenv`
  4. Run `.\myenv\Scripts\Activate.ps1`
  5. Run `pip`

Expected behavior: Get the pip usage commands list

Actual behavior: Get the above Fatal error

Notes:
I did not explicitly set case sensitivity on my machine. All my drives are formatted as NTFS, but should not be case sensitive, which can be confirmed by fsutils:

> fsutil.exe file queryCaseSensitiveInfo C:\
Case sensitive attribute on directory C:\ is disabled.

Attempting to actually call that python.exe using the full lowercase path throws a similar error. 

Someone I know who has been helping with debugging this ran the Scripts\activate script successfully on the same version of Powershell as mine (5.1.19041.1) which should be meant for use on bash. I however was not able to do so.

UPDATE:

After some further investigation, it seems like even on cmd and seeing the (myenv) indicator, it actually seems to be falling back to system pip and installing packages globally. Running `.\myenv\Scripts\pip.exe` actually throws that same error. CMD just seems to fallback to system pip and silently fails the desired venv pip, unlike Powershell.

> "C:\Users\chris\code\project\myenv\Scripts\python.exe"

Have you tried different case combinations for "Users" and "Scripts"?

    * C:\users\chris\code\project\myenv\scripts\python.exe
    * C:\users\chris\code\project\myenv\Scripts\python.exe
    * C:\Users\chris\code\project\myenv\scripts\python.exe
    * C:\Users\chris\code\project\myenv\Scripts\python.exe

> fsutil.exe file queryCaseSensitiveInfo C:\

Have you checked "C:\Users\chris\code\project\myenv"?

---

Off Topic

> Open Powershell (via both native Powershell app or the new 
> Windows Terminal) 

FYI, "native PowerShell app" is not the right way to think of this. Both cases run the same command-line interface (CLI) shell (i.e. pwsh.exe or powershell.exe), which is a console application that either inherits or allocates a console session (i.e. an instance of conhost.exe or openconsole.exe). When run from a graphical desktop application (e.g. explorer.exe), a console application usually has to allocate a new console session since there's none to inherit. Currently there's no way to set a default terminal for console applications, so a regular console session is allocated, which creates its own window. When run from a terminal in Windows 10 (e.g. Windows Terminal), a console application inherits a headless console session (i.e. pseudoconsole mode), and the user interface is provided by the terminal.

Another update:

After a full shutdown from yesterday and trying again today, everything seems to be working now, including activating the venv via:

  1. python -m venv myenv
  2. .\myenv\Scripts\activate (not Activate.ps1, though that work too, is this intended?)

The only thing I can think of that changed since I opened the report was that I changed my system locale back to English (United States) from Japan (Japan). I did a system restart to make the changes take effect, but it didn't seem to fix the issue at the time. It could possibly be a difference between a shutdown vs a restart. Odd, either way.

I wouldn't think that changing locales would have an effect on Windows paths being case sensitive or not, otherwise folks from other countries would be experiencing this error. Perhaps the mixing of locale and system language? I had locale set to Japan but system language set to English

Thank you for taking the time to reply.

> I wouldn't think that changing locales would have an effect on Windows
> paths being case sensitive or not, otherwise folks from other countries
> would be experiencing this error. Perhaps the mixing of locale and system
> language? I had locale set to Japan but system language set to English

It shouldn't make a difference. Filenames are Unicode, the NTFS case table is set on disk when the filesystem is formatted, and the launcher uses wide-character strings and calls CreateProcessW. I wish I could offer up a reasonable explanation, but I think this one stays in the category of strange problems fixed by turning it off and on again.