> 4. No drastically different file formats to parse (like binary module
> interfaces).

Exposed to the build system at least. I imagine there will be internal
formats for persisting this information on disk. I think the best that
can be asked for is documentation, but I don't know that is something
that build systems can require (tools doing static analysis may need to
know however).
Module maps are a thing in GCC and Clang, so they have it. Bikeshedding
on the format of it so that it can be shared among implementations would
be a nice-to-have in the TR.

I actually think that we should use this opportunity to switch to a standardized data format, such as JSON, that has parsers for basically every language (even make could use something like jq) for exchanging metadata between the compiler, build systems and other tools.

I really don't want to have to teach every tool to read Makefile syntax. It is also extremely limited in what it can tell you, and we may need/want a lot more kinds of data that it can provide.  Eg the hash that should be used to  detect thst the interface has changed in a way that doesn't need a rebuild of importers, or the list of bmi-altering flags in from the current command. 

And for the love of $diety, don't put any locale- sensitive strings in this metadata!