@Honza_Dvorsky and I were talking about something else in the "multiple modules, one target" space, which is when you have a Swift package with a bunch of different modules in order to enforce separation of concerns, intra-package layering, whatever, but where clients of the packages should always interact with the top-level module. This is similar to what I originally wrote (particularly about formalizing @_exported), but it's a little different because in this case you'd rather not expose the module name of these "sub-package implementation detail modules" outside of the package itself. (Ideally you wouldn't include it in the mangling either, so that you can move entities around without changing the ABI, but I'm not sure how to do that while still avoiding collisions.)
2 Likes