@jrose it’s great to know that you’re continuing to think about this topic. 
This is exactly the use case I think “submodules” should aim at addressing. It is a really important use case (especially in larger code bases) and is completely unserved by Swift today. Given the meaning of “module” in Swift today, “submodule” seems like the appropriate name for a feature in this space: something much like a module but without the overhead of an independent build target.
Related use cases include making some of these intra-target submodules visible to clients, allowing selective import, etc, but these features are ancillary to the fundamental concern of allowing programmers to express intra-target structure in a layered fashion.
Other use cases that are sometimes discussed when “submodules” come up are really more like namespaces. It isn’t yet clear to me that features in this direction provide sufficient benefit beyond caseless enums to justify their presence. That said, if sufficient motivation is presented I think a name other than “module” or “submodule” for a feature in this area would make the most sense.
So to summarize, +1 to thinking in the direction of your post. I would love to see this area explored in Swift 6 if possible.