I like the sound of resolved path identity from search, including the
constructed full path and the index within include paths. if I was writing a
compiler from scratch, i'd problem do something like this:
SHA2(include-path-search-offset-integer-of-found-header-to-support-include-next)
+
SHA2(container-relative-constructed-full-path-to-selected-header-during-include-search)
+ SHA2(selected-header-content) and make it timeless. if you evaluate the
search yourself, you have the constructed full path identity while you are
searching and you don't need to do tricks to to get a full container root
relative path because you already have it during the search. it's a forward
search path constructed relative root. what are the problems? it can include
the same file twice if it has two path identities (hardlink or symlink) yet
that seems the safer option to me because constant search configuration
relative identity sounds better. as they could be defined to be different
identities wrt #pragma once. it's the semantically safer option. and the
canonical example that fails (same content, different path, same mtime) would
succeed with this choice. pick holes in this. I might be overlooking something.
