I'd rather we leave the option of whether I care more about rebuilds and ABI stability vs optimization to then end project doing the compilation rather than mandating a specific set of tradeoffs
The underlying problem is deeper than that.
We have a multi-vendor ecosystem. A library author releasing a pre-built library needs to manage the ABI compatibility when making changes to that library.
That means it is imperative to have a definitive consistent answer to the question of "does this change require me to make a new SONAME for my library?".
Library authors that want to preserve ABI compatibility across releases need to use various techniques in order to allow changes without breaking compatibility (see also "How to write shared libraries", by Ulrich Drepper).
Module interface units introduce a new category for C++ code, as now we have non-inline functions that are technically available to the caller. Before modules, only inline functions could be visible to the call site.
There are two options:
1) non inline functions are visible to callers, which means they need to be treated as if they were inline for the purpose of managing compatibility.
2) non inline functions are not visible to callers, which means changes to their bodies have no impact on backwards compatibility.
I have no strong opinion one way or another. My only strong opinion is that this has to be a consensus in the entire ecosystem, and properly documented and communicated, so library authors can decide if they should put a non-inline function in the interface unit or move it to an implementation unit.
Daniel