It's almost impossible to get wrong though, because the same header will also be included in its own implementation. If there's a mismatch between the declaration and implementation you'll get at least compiler warnings.

It’s been a while, but IIRC there is no problem when you eg. change a struct, as long as the name is the same.

Indeed. Mismatching headers and libraries is not all that rare. I've seen headers found from Homebrew, libraries from the macOS SDK, and some related tool from `/usr`. Things…rarely work out well, but you only find out in your test suite (or linker if you're really lucky).

The only realword problem with headers I've seen so far is when there are multiple versions of the same header in the same project (bad idea anyway), and one isn't extremely careful about search paths.

The module equivalent would be different versions of the same module under the same import name. Can the C++ module system actually deal with that?

Modules don't have search paths unless you toss everything into one directory. The robust way is to instead do `-fmodule-path=modname=path/to/bmi` where ambiguity is non-existent. It is IFNDR to have two modules of the same name in a program (basically just a restatement of the ODR on the module initialization function). Due to the compatibilities, there may be more than one BMI for a single module in a build, but that module can only exist at link or run time once.