The main issue with ideas like "paths relative to the project" is that the compiler has no notion of a "project". It just takes a list of files from the command line and processes them, and they could be located anywhere on the filesystem. The closest thing is has is the current working directory (either inferred or passed via -working-directory). But even then, there's nothing that prevents it from accepting files that are outside of that directory.
There's probably a solution here, but it's more complex than it seems at first because it's easy to imagine situations where just moving a source file without making any other changes to its content could change a bunch of the generated symbols, which is a problem for build caching. Today, only a file's content, its basename, and the module name contribute to the names of those symbols.
The semantic result isn't all that matters; build systems might see that the output has changed and perform unnecessary rebuilds of downstream dependencies. As a general principle, it's always a good idea to reduce the amount of external state that can affect the output of your build.