Hi Experts,
 In a recent private meeting, we talked about the wording and the design intention for header units.
And the implementors get confused about how to implement header units again and we're wondering
if it is already specified in current wording clearly or what is the design intentions.
 First, the motivation example:
```
// a.cpp
import "foo.h";
// b.cpp
#define M 43
import "foo.h"
```
 The question is, for build systems, how can they know if they should use the same BMI for these
2 imports. Since **currently** the build systems don't have a **good** method to know whether a
macro is interesting to a specific file.
 Then we're looking for the wording to find solutions. (Tom suggested us to send this to CWG, but I guess
I found the concrete wording.) [module.import]p5 said (http://eel.is/c++draft/module.import#5 <http://eel.is/c++draft/module.import#5 >):
> Given two such module-import-declarations:
> - if their header-names identify different headers or source files ([cpp.include]), they import distinct header units;
> - otherwise, if they appear in the same translation unit, they import the same header unit;
> - otherwise, it is unspecified whether they import the same header unit.
 So it looks like it is unspecified in the wording intentionally. Then we're curious about what's the proposed solution
at the beginning.
 BTW, [module.import]p5 also introduces the implementation-defined concept "importable header", which is confusing
to developers and users.

---
(The section is about my personal thought about header units. The section may be a little not closed to the topic)
I can roughly understand that the designer didn't want to bring too much limitations to the implementors. 
(Or is it the reason that it is not good to insert module map like things into the formal wordings.)
But the consequence is that the C++ ecosystem is going to a more breaking state. For example, MSVC (or MSBuild?)
introduces header-units.json (https://learn.microsoft.com/en-us/cpp/build/reference/header-unit-json-reference?view=msvc-170 <https://learn.microsoft.com/en-us/cpp/build/reference/header-unit-json-reference?view=msvc-170 >).
And GCC has module map for named modules (I am not sure about gcc's state for header units). Clang has non-standard clang module
maps and doesn't have a solution for header units. It looks like things are not going right.
And I think a module map like thing is necessary for header units. For example, we can have header unit map to records the implementable
headers and the interesting macros. Maybe something like:
```
{
 "importable-headers": {
 "foo.h": ["Interesting Macro1", "Interesting Macro2", ...],
 "bar.h": [....]
 }
}
```
Then it solves the two issues raised in the mail:
(1) We know which headers are importable: except STL headers, only the headers specified in the header unit map
are importable.
(2) We know whether or not we should reuse the same BMI for header units: we can reuse the BMI for the header units
for which the interesting macro state and value are the same.
I heard there was a decision to not make module map standard and I agree it is somewhat weird to have things like module map
in the current wordings. But given we're going to have C++ ecosystem standard, is it possible to have a standard header unit map
(or module map)?
---
Thanks,
Chuanqi