Currently when using Set-Location (or it's cd alias) the FileSystem provider will use the literal text that is entered. For example:

Given a filesystem with following layout:

C:\
  |
  + Users
  + Windows

Issuing the following PowerShell commands results in:

PS C:\> cd Users
PS C:\Users> cd ..
PS C:\> cd users
PS C:\users>

Note - The last command used the path users instead of the actual name Users

This contrary to:

• Using tab completion
  Tab completion resolves to the name on disk

• "magic" paths like tilde (~)

PS C:\> cd ~
PS C:\Users\glenn.sarti>

• 8.3 Alternate names

PS C:\> cd C:\progra~1
PS C:\Program Files>

This can cause issues with child process creation, as the working directory passed to the child process, strictly speaking, does not exist. This is proved simply by calling cmd.exe:

Given the filesystem layout example above (C:\Users is the correct name, not C:\users)

C:\users> cmd.exe /c cd
C:\users

Note that cmd.exe outputs the "invalid" directory of C:\users

Note that, while strictly the fault of PowerShell, I have seen other cross-platform tools behave in strange ways (for example Ruby and NodeJS) where they are performing file path operations and raise errors because the current working directory is not what is on disk.

This appears to be "fixed" in PowerShell 7.x via #9250. This issue is to backport these fixes into PowerShell 6.x