Earlier versions of Mac OS had APIs to retrieve the IDs of directories and files relevant for things like installing applications (such as the the System direct

Earlier versions of Mac OS had APIs to retrieve the IDs of directories and files relevant for things like installing applications (such as the the System directory). It effectively never used paths to identify any files; if users opened a file, they'd use the system file picker, which would provide the application a file ID, not a path. Similarly, things like config files would be identified by their name, not their path, because the directory containing configs was a directory the system knew about. As a result, no application needed to know the path to its own config files. This meant there was no action that the system prevented you from doing to an open file, other than actually deleting that file. There was also no way for an installer to accidentally break your system because its code didn't take your drive, file, or directory names into account. And, of course, there are file systems that don't use paths at all, like HashFS, a bunch of modern document management systems, or the Newton's Soup. I get your point about interoperability with existing file systems, but I think it's perfectly acceptable to offer better solutions where possible, and fall back to paths for situations where that is not possible.