>    >>> sys.executable
>    'X:\\Python38\\python.exe'
>    >>> os.path.realpath(sys.executable)
>    '\\\\SERVER\\Programs\\Python38\\python.exe'

Unix Python resolves the executable path with repeated _Py_wreadlink calls. Windows Python should do something similar to ensure the consistency of sys.executable with realpath(sys.executable).

> different from mapped network and subst drives (AFAIU).

Mapped and subst drives are implemented as object-manager symlinks to file-system directories. For example, a subst drive "S:" might target a local directory such as r"\??\C:\Temp\Subst", and a mapped drive "M:" for an SMB share might target a path such as r"\Device\LanmanRedirector\;M:<logon session>\Server\Share\Temp\Mapped". 

The root directory of these drives does not behave like a real root directory unless the drive targets the root of a volume or UNC share, such as "\\??\\C:\\" or r"\Device\LanmanRedirector;M:<logon session>\Server\Share".

This means that in many cases it's possible to evaluate a relative symlink that traverses above the drive root via ".." components. Say we have a directory r"C:\Temp\Subst" that contains a relative symlink "foo_link" that targets r"..\foo". If we map "S:" to r"C:\Temp\Subst", then r"S:\foo_link" opens r"C:\Temp\foo". Similarly if we map r"\\localhost\C$\Temp\Subst" to "M:", then r"M:\foo_link" opens r"C:\Temp\foo".

In the above case, if we're using relpath() to compute the relative path to the "foo" target, I think we want relpath(realpath('C:/Temp/foo'), realpath('S:/')) to succeed as r"..\foo". I don't think we want it to fail as a cross-drive relative path.