But, going on past experience, those kinds of utilities/dependencies don't necessarily eventuate and I can understand the concern about proliferation/variation/lack of ubiquity in such things & so a preference to bake it into a common config file. I guess all I have on that is that I think it'd be unfortunate for developers to have to repeat this information in multiple places like that.
Right. In a sense, I'm putting forward a thesis that the heterogeneity that exists today on how to consume pre-built artifacts (pkg-config, CMake find modules, ad-hoc "pg_config"-style tools) becomes even more unsustainable after Modules, because of the separate parsing context for each module interface, and the required DAG-bound parsing of modules.
IOW, headers were trivial enough for the build system that we could survive the heterogeneity, but Modules have considerably more complex semantics, making the status-quo untenable for non-monorepo use cases.
daniel