So it turns out that Rust's import resolution is Really Fucking Complicated
https://devrant.molodetz.nl/Screens...
It supports glob re-exports and circular glob imports, conflicts are valid if you don't use them or if they ultimately point at the same name, paths may pass the same module multiple times. It's very convenient to use, I never needed to fight with it, but it's borderline impossible to correctly implement.

I definitely need glob imports in Orchid in some capacity because DSL authors should be able to create their own preludes, but I'm tempted to only allow a loop-free glob import chain, maybe even turn preludes into a special kind of module that can be targeted by glob-imports but isn't allowed to contain glob-imports itself.

Sometimes the realization of how complex simple appearing things are, makes you appreciate them even more.

Solution (for Orchid anyway): how a member is defined besides observable behaviour is an implementation detail with no versioning guarantees, so name conflicts shouldn't be hidden if all candidates happen to dealias to the same target; that would turn internally implementing a function your package previously imported into a breaking change even if your implementation was identical in observable behaviour.

Also I don't think I'll have bulk re-export, modules have a slightly different role in Orchid, they are sort of introspectable objects so adding new members should at least involve an edit to the specific module.

edit: This is probably cope tbh, but the deferred conflict problem is not.