Wouldn't that conflict with the fact that module itself stands as a "namespace" for its interfaces?
Personally, I try to think differently about imports from "in house packages" and "public" packages. For the first group it's more relevant to have stuff in global namespace (to some degree) as it's closely related to the project domain and commonly used. For example, domain package like "Core".
For the second group I think you shouldn't allow 3rd party naming to leak into your codebase, so creating a small wrapping layer in which you need to force yourself to make that long type chain isn't that bad.
Although it would be awesome to have some concept of using keyword it could also cause a lot of API leaks all around and hard to trace problems.
There is this comment on name spacing Namespacing - #6 by clayellis mentioning apple definition of Combine Publishers, if you're creating API for very generic usage it's probably a good idea to approach it like that to prevent conflicts with codebases importing your lib. But in the discussion example if the Dreamhousing would be team owned package. Then types such as Garage or Pool could live outside the Dreamhouse unless they are of course tightly coupled with the Dreamhouse itself, but then why would we need to work with this api a lot outside the Dreamhouse?
My point is nesting types to me is a sign that those types are closely related to each other (otherwise you wouldn't define one inside the other?) and most probably the owning type will be handling most of the stuff related to the child type. Which would focus my attention towards extending that type closer to its original definition, like in the library itself.