Full disclosure, I haven’t needed to write a package extension, yet. But first impressions, importing names originating in an extension sounds like a nightmare. I wouldn’t want to do using Draw, Rainbow: DrawRainbowType to get a name DrawRainbowType that belongs to neither Draw nor Rainbow alone. Extensions can’t be imported, just implicitly loaded, so if you somehow work around that to export new names, there’s no good way to organize them. There’s no reasonable choice of one package over the others when categorizing names into module instances (parentmodule(DrawRainbowType), names(Draw)) or documentations. If names were associated with and documented for the extension separately, I would rather that be an explicitly importable package DrawRainbowPlus that depends on Draw and Rainbow; this is much more accessible and a lot less misleading. After all, modules are Julia’s namespaces, so it’s intuitive that names that don’t originate in 2 spaces belong to a 3rd space that is handled the same. On the other hand, mixing names originating in Draw and Rainbow is more appropriate in an implicit extension than in a 3rd package dedicated to type piracy and re-exports. Making the unreasonable choice of one of the packages to export new names is not good either; it goes against modular programming principles for a module to expose conditionally existing names, especially if they depend on other modules’ independent existences.
There is a documentation issue describing how to access extension-internal names, and you optionally bind to new variables instead of importing names. It looks awkward enough that it doesn’t seem intended for general usage. If it helps, here’s an example of how new variables differ from imported names, without involving extensions.