The realpath function is kind of a problem child. See #34132 and JuliaLang/Pkg.jl#1547 for cases where it is necessary to jump through all sorts of hoops to make sure that realpath, instead of just crashing and burning, does something reasonable. In both cases there were already previously some kind of protections for various failure cases around these usages of realpath. On the other hand, realpath is in libc and we don't really want to go around changing what it does willy nilly. There seem to be two kinds of issues that are encountered:

1. The full path doesn't exist, in which case the libc function fails. In this case, what people actually want is an answer to the question: if I created this path, what would its realpath be? In other words, resolve symlinks in the path prefix that does exist, normalize out . and .. entries and leave the non-existent part of the path alone.

2. On some filesystems (e.g. network drives), it's possible that the user can read contents later in the path but not earlier in the path, but realpath requires being able to read each prefix of the full path in order to do the normalization. It might be better in such cases to just take whatever is given at face value and move on, even if that isn't guaranteed to give a fully globally "realized" path. This would be far less all or nothing than the current workaround of just trying realpath and giving up and returning the original path as is if anything goes wrong.

Arguably, both of these are non-breaking changes, since code that previously worked will continue to work, but I do worry about making changes to what is generally expected to be a system function. These changes sound very expensive, but realpath is already so expensive that I doubt that it matters.