It's actually a very hard problem to know whether two paths are really the "same file" or not.  That's why make uses a simple textual comparison and leaves it at that (it does try one trivial simplification: it treats the targets "./foo" and "foo" as the same).

If we were to limit ourselves to traditional POSIX-style filesystems then we could use a combination of device ID and inode, which should be unique.  However, it's not clear all other filesystems have similar facilities so portability might be an issue.

Assuming we could come up with a portable way to uniquely identify that one file was reachable via different paths, then it would probably not be too bad to have make detect this situation at runtime, but only if it were actually going to build both targets in the same instance of make.  We could just remember the unique ID of all the targets we've already built and if we find a different target with the same unique ID as one we have remembered, we could write a warning or fail the build.  Then it would be up to users to fix their makefiles.

You wouldn't get any notification if you only built one of the "duplicate" paths and not the other in a given invocation of make.

I don't see any realistic way that make could magically coalesce two such targets into one and "fix up" this mistake on its own.

Also, I'm pretty sure having make fail if it detected this situation would be considered a violation of POSIX.

I will leave this enhancement request open for now, to think about.