Currently we do agressively path normalizations by replacing '/' with '\' on Windows and '\' with '/' on Unix. NormalizePath()
It is acceptable for Windows but has side affects on Unix because '\' is valid char in directory/file names.

.Net Core do the same for Windows but don't the normalization for Unix.
IsPathRooted on Unix (IsDirectorySeparator)
IsPathRooted on Windows (IsDirectorySeparator)

NormalizeDirectorySeparators on Unix
NormalizeDirectorySeparators on Windows

As you see Unix takes into account only '/' and Windows both '\' and '/'.

Should we follow .Net Core in the path normalization?

Related issues:

• Set-Location preserves case instead of matching filesystem on case-insensitive/preserving system Set-Location preserves case instead of matching filesystem on case-insensitive/preserving system #5678

• Location completion should be case-insensitive Location completion should be case-insensitive #1273

• Bug: can not handle "/" correctly when reading registry item Bug: can not handle "/" correctly when reading registry item #5536

• Replace string-compare-based test for copying to same file with more Replace string-compare-based test for copying to same file with more … #3441

• File mode in Linux should reflect Linux modes File mode in Linux should reflect Linux modes #1817

• History Fix path normalization #1115

• On Unix, PowerShell will not find files with backslashes in their names On Unix, PowerShell will not find files with backslashes in their names #3666

• New-Item -ItemType SymbolicLink should support creating symlinks with relative paths New-Item -ItemType SymbolicLink should support creating symlinks with relative paths #3500.

Simple side affect repo on Unix below:

Steps to reproduce

mkdir /\

cd \
$pwd

Expected behavior

\

Actual behavior

/