Perhaps related: #9293

Steps to reproduce

Run the following on Windows (works analogously on Unix):

Set-Location Microsoft.PowerShell.Core\FileSystem::C:\Windows
"$PWD" | Should -Be C:\Windows

Note: A real-life scenario in which this could occur is if you pipe the output from a New-Item -Type Directory call to Set-Location, e.g.:

New-Item -Type Directory $HOME -Force | Set-Location

Expected behavior

The test should pass.

Actual behavior

The test fails:

Expected strings to be the same, but they were different.
Expected length: 10
Actual length:   48
Strings differ at index 0.
Expected: 'C:\Windows'
But was:  'Microsoft....'

That is, $PWD stringified (via .Path) to 'Microsoft.PowerShell.Core\FileSystem::C:\Windows', not the expected C:\Windows, as also reflected in the prompt string afterwards (via $executionContext.SessionState.Path.CurrentLocation).

While $PWD.ProviderPath does reflect the unprefixed (but always native) fileysystem path, relying on "$PWD" or $PWD.Path to do that too is very common.

Environment data

PowerShell Core 7.0.0-preview.3