It requires out-of-band information, period.
The paper doesn't change that. Someone still needs to specify a Resource
Path for std::embed (or anything else related to resources) to work. Similarly, someone must
also specify Include Paths in order to do the first build. Either that, or
you come to an agreement with your build tool that you will obey a
specific layout, and the build tool will work with that assumption so it can get through a first pass over your code. Neither of these change that the information is outside of the specification of your include statements.
Modules do not map directly to any file system schema, nor any namespace schema. It's all wild wild west, so again you need out-of-band information in order to coordinate anything. I haven't made the situation any better, or worse, but if the cost of doing full semantic analysis is cheap enough to use then I'd want that to be the case. I have no indication from any implementers that that is desirable.
Colby:
That sounds fairly correct, though as of right now I do not know how to, e.g., export such information post-compilation for any build system to pick up. What compiler flags make visible post-compilation dependency information? From reading ninja documentation, I only see that they use /showIncludes for VC++ and -MMD-style Makefile-like depfile reading. Neither of these perform full semantic analysis to help get the build system going (they do preprocessing + a few other steps, but never semantic analysis), so I'm curious where I would find this information?