Correct me if I'm wrong, but I believe the parent comment's strategy of only #including header files within .c files only helps reduce duplicate header file parsing within each compilation unit. So it wouldn't do anything to improve the case you mention (duplicate header compilation across compilation units) anyway, while adding much additional overhead in manually tracking header file dependencies.
Also, given your experience in compilers - keen to see if you agree that because modern compilers optimize away re-scanning of the same header file within a compilation unit anyway (in the presence of include guards), the strategy of only #including header files within .c files is close to useless.
The not rescanning if the #include guards are there goes back to the mid 1980s. It's not a modern feature :-)
> the strategy of only #including header files within .c files is close to useless
It probably is. It also means the user of the .h file has to manage the .h file's dependencies, which is not the best practice. .h files should be self-contained.
Also, given your experience in compilers - keen to see if you agree that because modern compilers optimize away re-scanning of the same header file within a compilation unit anyway (in the presence of include guards), the strategy of only #including header files within .c files is close to useless.