Modifying readlink() to return an str subclass that preserves the print name is an interesting idea, but not on topic here. 

For the cases where os.readlink is used to manually follow links (*), such as ntpath.realpath, using the substitute name is the most reliable option since that's the actual path that the system uses. But this issue is about the use of os.readlink in order to copy symlinks in shutil.move, shutil.copyfile, and shutil.copytree. I'd still be happy to assist with the development of an os.copylink function that copies the reparse point exactly via low-level FSCTL_GET_REPARSE_POINT and FSCTL_SET_REPARSE_POINT. It has to use the low-level API because it turns out that CopyFileExW and CreateDirectoryExW fail if they can't enable the symlink privilege, which is not actually required if the system is in developer mode. For shutil, it would be used as shutil._copylink. In POSIX, shutil._copylink would continue to just use readlink and symlink.

---

(*) off-topic note

Manually following remote mountpoints is never correct. They are intended to be evaluated by the remote system using its local devices. 

Manually following remote-to-local (R2L) symlinks is almost always incorrect and should be disallowed by local symlink evaluation policy Check `fsutil behavior query symlinkevaluation`. A remote SMB server opens a path in a way that has the remote I/O manager stop parsing at the first symlink, which may be a directory symlink in the path (it's not necessarily the final component, unlike FILE_FLAG_OPEN_REPARSE_POINT). The server completes the request with a message to the client redirector that contains the parsed path of the symlink, the remaining unparsed path, and the target of the symlink. The local SMB redirector decides whether to allow reparsing based on its L2L, L2R, R2L, and R2R symlink policies. This reparse is implemented locally, with local devices. It is unlikely that a non-relative symlink that targets local device paths (e.g. "//server/share/symlink" -> "E:/work/file") was intended to be evaluated on another machine, so R2L should almost always be disallowed. Bypassing the system's R2L policy when manually following a symlink is always wrong.