I do think it would be worth just a smidge of lookahead to think about how module-level and package-level export declarations should/would interact with this feature.
For example: it would be reasonable to argue that package manifests MUST (in the RFC 2119 sense) explicitly declare public exports in order for them to be declared public in individual files. Is that in fact desirable? If so, what’s the migration path? Does the migration path get complicated if this SE is accepted first?
It would be interesting to have a general discussion on how to organize many modules in a package. The proposal for the package access-level modifier and discussion touched a similar problem for big packages that may need to be broken down into layers or groups. For this proposal goals, the solution I would lean towards is to declare the layer of each module in the manifest.
There's partial support for something similar in the compiler aligned with the @_spi experimental feature. Each module can be marked as either API or SPI. The compiler then raises an error when an API module imports publicly an SPI module or a private clang module.
I think we could use something similar in packages where we'd mark some modules as being visible to clients and some to be package-internal only. Similarly for dependencies that could be marked as exported or for package-internal use only. For backwards compatibility, modules could default to the visible layer, and optionally be moved to the package-internal layer. The compiler can then enforce how modules are imported in sources from the intent declared in the manifest.