Arguably, a WindowsPath instance only represents the *path* and not the file located by the path. So the programmer has to take just as much responsibility as if they were using plain strings, except there are some conveniences added to make those strings easier to manage.

I don't see anything in the docs suggesting that a Path instances have file-identity (that is, two Path objects are always equal if they refer to the same file). Even the "resolve()" method doesn't pretend to get the exact filename.

The best option for true comparison is to use stat() and compare st_inode and st_dev. Lacking that, doing a good enough job of case folding is better than ignoring it, as most workarounds are likely to do a worse job (e.g., they won't even correct for "A"=="B\..\A", let alone casing).

If you have a specific suggestion for how comparison could be improved here without having to go to kernel mode, feel free to make it. Unfortunately, your two suggestions here are not workable.

(And yes, PurePosixPath and "import posixpath" are the right way to handle case-sensitive paths explicitly, which is why they're available on all platforms.)