For the interfaces in C, it looks as easy as it was for F77 compilers, as the interfaces are simple. And on unix systems, different compilers can just use the libc provided by the system and that’s it.
AFAIK, C++ faces similar ABI compatibility issues between compilers as Fortran. However, it seems that many compilers tend to follow the Itanium C++ ABI (which is not part of the C++ standard).
Interesting – I have thought of creating such files, except that comments at the beginning of a function and in argument declarations would be retained. The procedures in a module should be documented well enough that the reader (either a human or an LLM) does not need to look at procedure bodies to understand what they do. If an LLM only needs to read such a “module file” to understand a code, it should be faster and cost less to complete a task.
Fortran 77 compilers were not interoperable either, particularly when i/o was involved, but also the libraries that supported the intrinsic functions were often not interoperable. Most machines only had one fortran compiler, so this issue was not always apparent, but especially after g77 and also other commercial compilers (absoft, pgi, etc.) became available in addition to the vendor fortran compiler, then this became apparent. In contrast, gcc was usually compatible with vendor-supplied C compilers.
I am unaware of any similar document that has ever been written for fortran.
I have a display subroutine for many derived types defined in different modules. It can be convenient to reuse names across modules for procedures with analogous functionality. If each display subroutine is a module procedure with an interface, you can access display subroutines from numerous modules in the same program unit.
Thanks ! I will wander down that rabbit hole later in the year.