In short, don't load modules threaded unless it works...
--threading tends to break scripts.

This Module Manager is best for use with less interactive/visual directly-manipulated modules, perhaps.

It doesn't address hooking. "Rehooking", as Cerbie has experimented with can be tricky so I choose to avoid that until it can be reliably done.

For those modules that are hooked, I don't know. It's really beyond the scope and intent of this script.

The modules that do provide hooking should be left loaded all the time IMO. This is what the persistent flag mechanism does: ignore a module. In theory you could load most modules through this Module Manager but I don't think it's practical. After all, a theme is there to keep a minimum set of modules loaded.

The Module Manager ultimately loads and unloads modules by request, trying to be fair...

Some themes insist on doing that for some modules: like if you don't show a module, you may as well unload it instead of hiding it. But if you need to use the module for another reason somewhere else, whether it be in another part of the theme, or in your personal scripts (at least I have them :), then the module should be kept loaded.

But modules that aren't needed can then be unloaded, obviously to free up memory. I can't say if the overhead and complexity of this Module Manager makes it worth using to the extent that it functions for its goals; it depends how it is used.

Also, different module versions can be very different to where there are incompatibilities anyway, amongst scripts; this system doesn't do anything about that.

I said in the post that it cannot address memory leaks. Actually the system is in place to reduce recycles, which just unloads all modules and reloads them all. In this sense then, keep loaded the modules that leak on recycles. :D