I think the primer hits here are real issues

Sounds good, I'll leave open for a bit in case anyone else chimes in!

Here is a small regression that this PR causes, FYI: currently mypy will not complain about this code (on my Windows machine, the expression evaluates to True):

from pathlib import *
PureWindowsPath("foo/bar") == Path("foo/bar")

But with this PR, it will:

$ mypy -c "from pathlib import *; PureWindowsPath('foo/bar') == Path('foo/bar')" --strict-equality --custom-typeshed-dir .
<string>:1: error: Non-overlapping equality check (left operand type: "PureWindowsPath", right operand type: "Path")  [comparison-overlap]
Found 1 error in 1 file (checked 1 source file)

Is the regression that important? Probably not particularly; I don't know how many people are doing this kind of comparison. But, worth noting, I think.

@AlexWaygood oh, interesting example! Definitely a false positive in terms of what the type checker thinks it's doing, but that code is pretty suspect and I'm okay with it triggering a warning of some kind — depending on your platform, it could be true that those could never be equal!

So I think I'm still fine with the PR (though I'll certainly add test case and comments). We should experiment with making Path.__new__ more accurate in a follow up. I'm trying to teach mypy about more kinds of __new__ over here: python/mypy#16020

Diff from mypy_primer, showing the effect of this PR on open source code:

mkosi (https://github.com/systemd/mkosi)
+ mkosi/kmod.py:32:16: error: Non-overlapping container check (element type: "str", container item type: "Path")  [comparison-overlap]
+ mkosi/config.py:2012:8: error: Non-overlapping equality check (left operand type: "Optional[Path]", right operand type: "Literal['']")  [comparison-overlap]

This change caught a real bug in stubtest (that was introduced by, er, me)! https://github.com/python/mypy/actions/runs/6202155467/job/16840319289?pr=16121

The first CI run on python/mypy#16121