My Windows user name is Alexandre, which is more than 8 characters long. Creating temporary directories gives me paths which are in "8.3" format:

C:\Users\Alexandre>amm -c "println(os.temp())"
Compiling C:\Users\Alexandre\(console)
C:\Users\ALEXAN~1\AppData\Local\Temp\2085325879310438089.tmp

(with ALEXAN~1 rather than Alexandre in the path).

In this case, we have p != os.Path(p.toIO.getCanonicalFile), which is surprising I think:

C:\Users\Alexandre>amm -c "val p = os.temp(); println(p == os.Path(p.toNIO.normalize)); println(p == os.Path(p.toIO.getCanonicalFile))"
Compiling C:\Users\Alexandre\(console)
true
false

That originates from the different handling of the 8.3 / long paths, calling java.io.File.getCanonicalFile on those files rather than java.nio.file.Path.normalize returns different paths:

C:\Users\Alexandre>amm -c "val p = os.temp(); println(\"NIO: \" + p.toNIO); println(\" IO: \" + p.toIO.getCanonicalFile)"
Compiling C:\Users\Alexandre\(console)
NIO: C:\Users\ALEXAN~1\AppData\Local\Temp\2933120367880475586.tmp
 IO: C:\Users\Alexandre\AppData\Local\Temp\2933120367880475586.tmp

It seems File.getCanonicalFile calls GetLongPathName while Path.normalize doesn't.

I don't know if anyone has an opinion about this. I'd argue the paths returned by getCanonicalFile are more "normal", and should be used by default here. In particular, I've had issues with a downstream library calling getCanonicalFile at some point, which returned apparently different paths than os-lib.

I can send a PR to replace the few uses of Path.normalize by File.getCanonicalFile if everyone is fine with it.