Why do you need more than one C++ compiler installed? The idea is to compile everything only once, and save all the time when you need to use the code later.
It makes no sense not to use the same compiler against all the source when building an executable.
This means that realistically, even if every machine only has one C++ compiler installed, binaries compiled with different compilers will need to be able to interface with one another. Changing a language's ABI is a really, really big deal and not having a defined ABI at all is even worse.
[WARNING: I don't really know that much about the C++ modules proposed by ISO. Please feel free to jump in and correct me.]
Okay, lets assume that everyone is using the same compiler.
The problem is that, when someone hands me a `foo.bmi` to use in my project, even if I am using the same compiler that they did, the `foo.bmi` might not be compatible because they used different compile-time flags (Maybe they've removed padding between structs, maybe they specified a 64bit `time_t` using a compile-time flag).
This problem makes it no different to handing someone a `foo.o` file and a `foo.h` file (header having templates in them, or similar).
Modules were supposed to solve the problems with headers, not replicate them.
> The idea is to compile everything only once, and save all the time when you need to use the code later.
I agree, but there are real problems with C++ other than using a different compiler.
Command-line/compile-time flags will produce `.o` files that are incompatible with each other. Templates are challenging to put into compiled libraries/modules. `#ifdef` directives have to be supported in any source for a module, making repeated compilations of the same source result in different output. `#include` directives might include `system/headers.h` that also cause different output with the same module name.
All-in-all, it may be a lost cause; ISO C++ modules are far too abstracted (as I understand it) to be practically useful. If the specification included some sort of readable header in the output file `foo.bmi` that contains practical but non-portable information like compiler name, compiler version, compiler flags, host name, target name, etc then C++ modules become easier in practice because a compiler can simply reject a module that it is not compatible with, with reasonable error messages ("User specified -DTIMET_SIZE=64 but foo.bmi is compiled with -DTIMET_SIZE=32").
It's hard to do C++ modules both usefully and portably[1]. When trading off between utility and portability, ISO is almost always going to weight portability more than utility.
[1] I once got a support ticket from a user who was porting my FLOSS library to zOS, and when trying to solve the compilation problems I learned that C++ (the language) is insanely portable. The build systems are not.
All the problems that we had were build-time problems (#ifdef for different archs, compile-time flags that needed to be used to make the library compatible, etc).
Sometimes you need to upgrade your compiler but can't/don't want to rebuild the whole dependency graph.
Because sometimes you need to import prebuilt libraries/modules provided by a third party, and you don't control how those were built.
Keep in mind that C++ does not define a standard ABI.