Many applications on Windows (e.g. the Chocolatey wrapper) do not work when current_dir is a canonicalized path

I found a "weird" issue with std::process::Command and canonicalized paths on Windows. Something like (which assumes lsd is installed on the machine):

let p1 = Path::new(".");
let p2 = p1.canonicalize().unwrap();

let e = std::process::Command::new("lsd").current_dir(&p1).spawn().wait_for_output().unwrap();
println!("P1 = {e:?}");

let e = std::process::Command::new("lsd").current_dir(&p2).spawn().wait_for_output().unwrap();
println!("P2 = {e:?}");

... works fine for the first execution, showing the current directory contents; but the second execution fails with

Unhandled Exception: System.ArgumentException: Illegal characters in path.
   at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
   at System.IO.Directory.InternalGetCurrentDirectory(Boolean checkHost)
   at shim.ShimProgram.Main(String[] args)

... which looks like it is caused due .canonicalize() prefixing the path with "\\?\" -- which, for what I can understand, correct, telling Windows that the path must be taken as-in, without any processing.

Meta

rustc --version --verbose:

rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1

Also note that I'm cross-compiling from Linux to Windows, using "x86_64-pc-windows-gnu" as target triple.

Start by reproducing the Windows behavior with std::process::Command::current_dir using both . and its canonicalized path, targeting x86_64-pc-windows-gnu. Trace the Windows process-launch and path handling involved; done means applications launch successfully when current_dir receives a canonicalized path without the reported path error.