Right now I think we're essentially using one webpack loader per extension.
Webpack optimizes variable names, so while everything might technically be available globally, it cannot be retrieved via its relative or absolute name like it can be during compilation. I'm not sure whether that webpack loader object is actually global, it might be a variable that's re-created for each extension so there might be no way to access it at all from other extensions at the moment.
We might be able to write a webpack plugin that adds everything it parses to a global object in a similar structure to the compat object. Then just like we currently configure webpack to resolve flarum/* through the compat object, we could resolve all unknown imports through another global object that would also include extension.
This seems perfectly doable. Webpack plugins must have access to all those details during parsing. I guess it simply doesn't exist because it's not a typical use case to compile multiple different codebases with webpack and then concatenate them together. It does create difficulties because now if an import fails it fails at runtime and not compilation, but we have no choice with pre-compiled extensions.
On that note, it would be useful to define a behavior for invalid imports. Right now with useExtensions or compat, you get cryptic <something> is undefined, or cannot read property of undefined errors which new developers might not understand and which cannot be troubleshooted without going into the debugger. However it has the benefit of letting you import classes that might exist from another extension at the top of the file instead of having to manually retrieve everything where it's used in case it's not available.
