Thanks. After your previous response, I actually visited the AngelScript to-do page and noticed what improvements you had in mind. Our team was discussing whether to adapt a similar approach, but for now I'll be trying something different. It's a similar concept, but rather than import functions, I'm importing interfaces. The exporting module registers a class C that implements a shared interface B, which in turn inherits from an application-registered empty interface A. It also registers a hook that returns an instance of class C. The importing module calls an application-registered function that calls the hook in another module and returns its result as a handle to A. This result is then cast to a handle of B, which is possible because it is shared. This way the importing module can call methods of an instance in another module.
This approach is not as straightforward as imports, but it has its advantages. It's safer, because a module may only import a selection of functions that are meant to be imported, rather than just any function it desires. On the importing side of the code, it often ends up shorter, because a single import gives the script access to all functions of another module (the shared interface B can be placed in a separate header file that just has to be #included). The most complicated part of code ends up on the exporting side, which I think is a fair price, because I expect modules that expose a functionality, akin to libraries, to be only written by the more experienced users.