>> We can find code that does `relpath(realpath(target), 
>> realpath(start))` to compute the relative path to target 
>> for a symlink. 
>> ...
> I don't know how common this scenario is, but I can certainly 
> say that it's never worked on Windows. You'd also end up with a 
> relative symlink in a _real_ directory somewhere (that the 
> junction was pointing at) that is unable to reach `target`, 
> because it's now being resolved against the wrong start.

With ntpath.realpath == ntpath.abspath, it actually works fine for just junctions because in most cases a mount point in Windows should be handled simply as just a directory, not resolved as its target. Revisit my example. This is what I showed when "C:/spam/scripts" is a junction. It's only wrong if the junction targets a directory symlink -- a chimeric mount-point-link that NT has made the mistake of allowing. (The kernel developers should have known to disallow this when they introduced Unix-like symlinks. When evaluating a mount point that targets a symlink, or any name-surrogate reparse point, it should fail the call as an invalid reparse point. For simplicity and our sanity, a mount point should always have consistent semantics in path parsing as a hard component that behaves like a regular directory. Then we could *always* handle it as just a directory -- whether it's local or remote. They messed up badly, IMO.)