I've been testing the new dependent modules branch and managed to get saving / loading modules working correctly with opaque types.
There are, at least at the moment, some restrictions. saveModule creates a new module but this is not recorded in the exporting process. So exporting two modules from the same Poly/ML session will not work as you might expect. The answer is to call saveModule as the last action in a session. Then start a new session, load the module just saved along with any others, add some more declarations and create a new, dependent, module. The dependencies must be loaded explicitly before a dependent module can be loaded.
That is unfortunately not applicable here, but reloading the module instead of restarting into a new session seems to work.
There is no mechanism to load dependencies automatically.
From what you've said I think this should be sufficient for MLB. I would assume that the implementation can keep track of the dependencies.
Dependencies are already tracked, so loading them before a dependent module is fairly simple.
I have however ran into a single problem, which is that a new module seems to depend on all previously loaded modules, even if nothing seems to be shared. Attempting to load a module fails with "Mismatch for existing memory space". Attached is an example in which two modules, each containing a single value, are exported sequentially. Trying to load the second one without the first fails. Interestingly, it works fine if the modules are exported from different threads.