Hi Experts,
 There is a discussion about ABI in modules in https://github.com/itanium-cxx-abi/cxx-abi/issues/170 <https://github.com/itanium-cxx-abi/cxx-abi/issues/170 >.
 John Said:
> Okay. The committee needs to understand that that's not how this works, alright? Whenever the language adds new constructs, compilers have to figure out how to compile them, and that needs to go into this specification. Modules add quite a few new constructs, and they have non-trivial implications for compilers because they create new kinds of information flow between translation units. The traditional understanding of ABI boundaries in C++ has always been that any information in the translation unit is fair game for the compiler to use. A perhaps-naive understanding of how importing a module interface unit works is that the exported declarations from that module are now available in the importing translation unit essentially as if they were declared there (just preserving the knowledge that they in fact came from a different module). So if the idea is now that some of the information in a module interface unit is not supposed to be used by its importers, that's an important shift. That's true even if you've identified a reasonable formalism that seems to unify previous behavior with the new intended interpretation, because compilers need to make sure they're implementing the intent of that formalism.
 Then I feel it is worth to bring the topic here. Should we try to summarize a precise ABI expectation for modules? And if yes, how should we get involved in? And although it is not required to be formal, I feel a paper might be a good outcome.
 BTW, previously I sent a discussion about ABI in modules to SG15 (https://lists.isocpp.org/sg15/2023/11/2064.php <https://lists.isocpp.org/sg15/2023/11/2064.php >) as I think it is implementation details. But given what John said, I feel it may be worthy to bring this to EWG too.
Thanks,
Chuanqi