The trouble with symbolic links

I imagine that either all userspace programs will get recursively following symlinks right, or they'll all get it wrong, since I think it would be done in libc and they'd all use the same implementation. For that matter, I think the implementation should probably be a system call that takes a path that may use symlinks and returns a path that doesn't use symlinks, in which case everyone would end up using the correct implementation that the kernel uses.

The only change I can see to outcomes of path-based operations from having separate resolve and operate syscalls would be that, if you rename a symlink over a regular file, a poorly-timed open() could get ELOOP instead of either getting the original file or the target of the symlink. Replacing one symlink with another would be atomic, and any other operation isn't atomic today (that is, you can't replace a directory with a symlink atomically, and you can't replace both a symlink and another file atomically; I guess you might get ELOOP when you could only have gotten ENOENT).

As far as changes to userspace program code, the only one would be that, if you've explicitly called realpath() yourself and validated the result in some way, you'd call realopen() on the string you validated rather than calling open() and getting another round of symlink resolution that might be different.