> We can find code that does `relpath(realpath(target), realpath(start))` to compute the relative path to target for a symlink. 

> In other words, the caller wants a solidified form of `start` that can be used to compute the path to a target for a relative symlink, but one that works when accessed from `start`, not the final path of `start`. 

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.

Relative symlinks are nearly as evil as symlink loops :)

Given there is no POSIX concept of a "final" path, a real path is the closest analogy. If this is the quality of edge case where that happens to break down, I'm okay with leaving it broken.

(Similarly for the junction/symlink combination on remote systems. I don't see any way that POSIX emulation can properly support that, but it seems like the far more rare case - and I say this as someone whose employer *lives and breathes* unnecessarily complicated SMB shares ;) I've never seen this become an issue.)