I've worked extensively on module/import semantics for multiple products in my life. It is complex. However this complexity is on the implementer and not the user.
If "best practices" need to be refined over years, it is poorly designed. This is not untrodden ground, other languages and ecosystems do sane things.
This was considered during standardization. The feeling among tool developers at the time was it was "close enough" to Fortran modules to be mostly solvable.
This was wrong, mostly because C++ compiler flag semantics are far more complicated than in Fortran, you live and you learn. The bones of most implementations is identical to Fortran though, we got a ~3 year head start on the work because of that.
Ninja already had the dyndep patch ready to go from Fortran, CMake knew basically how to use scanners in build steps. However, it took longer than expected to get scanner support into the compilers, which then delayed everything downstream. Understanding when BMIs need to be rebuilt is still tricky. Packaging formats needed to be updated to understand module maps, etc, etc.
Each step took a little longer than was initially hoped, and delays snowballed a bit. We'll get there.
