I agree with the logic, but isn’t the caveat a bit extreme to begin with? Say there’s a package that does @useall its dependencies and does all the crazy things that PatrickHaecker is warning against. That mostly doesn’t matter to the package’s users unless ExportAll.jl, which is in General, is also used to expose all those names to them. There’s an argument here that a package developer is free to do generally bad practices (like relying on internals) when it makes sense and isn’t exposed, and a runtime warning wouldn’t really help then. It’s already quite easy to check a package’s Project.toml for UseAll, and it’d show up in Manifest.toml if an indirect dependency ever uses it (but factcheck me if test dependencies also show up, which we may want to ignore). Dependency tree reflection for a particular dependency would be nice though; I think there was a related package announced recently.
You could support a secondary syntax @useall using .MyModule like Reexport.jl.
That would actually work great in conjunction with this package because it’s easy to run into import name conflicts upon multiple implicit imports, and @useall introduces more names per module that could conflict. There is an element of chance here, but the chance is very high for the standardized @main() resolving to :main. Dumping Main into each package would be less conflicting than dumping many packages into Main, but namespace baggage in our actual projects is a session-irreversible source of bugs. Either way, it’d necessitate a time-consuming session restart.
To minimize the number of possibly conflicting modules and to partially put the “temporarily” in the title, we can make and switch to throwaway submodules in Main just for REPL experimentation, and each one can isolate a pair of @useall Main; @useall MyModule. If that still causes issues, we can make another Main submodule and rename some imports instead of @useall Main, maybe work with new isolated globals. Those modules aren’t really temporary because they’re all kept alive in the session, but they don’t affect other modules and we can switch away for the rest of the session.