I think that says more about Microsoft's poor optimisation of #include <iostream> semantic caching.

There's no good, fundamental reason why #include caching can't be done with similar mechanisms to import, resulting in similar perfornance.

Certainly, modules are cleaner than headers. That's a language improvement and a fine reason to switch to them. Headers leak more definitions, macros etc that are part of the implementation, and their interpretation is affected by definitions before the header is included.

But in normal situations those header semantic leaks need only add a very small or negligible time overhead to symbol resolution compared with modules, both from a compiler-friendly precompiled form. Articles I've see explaining why modules are faster tend to talk about parsing headers, repeatedly, and if not parse then still process a precompiled syntax in some complicated way, as opposed to modules storing a compiler-friendly data structure. But those are merely describing how things are already done, not what's possible.

Visual Studio has one of the best precompiled headers implementations.

So I would take a few minutes before wondering how bad they handled #includes.

Precompiled headers exist in the PC world, across all major compilers, since Windows 3.x days.

But clang and GCC have not reported anything (it doesn't work), but they have always been careful to not get people's hopes up

How could they?

Their module support barely works, and will take a couple of years to catch up to VC++.

Other C++ compilers are even more behind in regards to catching up to ISO C++.

Exactly. They have been cautious about claiming if modules will actually speed up compilation when they arrive. They might be a visual studio only win for speed. (Still useful for simplicity over include files)