This is the proper way to do a plugin's api, but unfortunately no one has the time to do it or enough personal need for it.
A vote for personal need... In the attached patch, I've started playing with deferring the loading of plugins until they are actually needed. The patch has some issues with installing new plugins and makes the already weak encapsulation of pluginmanager stuff worse, but it MOSTLY works.
I am now thinking about how to address the dependencies between plugins. Instead of dependent and independent, I think it makes more sense for each plugin to state their dependencies in the manifest. So if plugin A depends on the compiler plugin, then when the user disables the compiler plugin, the framework will know to disable plugin A first. Thoughts?
Btw, does anyone know how to update the shared library search directories from within C::B at runtime? By default, the plugin dirs are not in the library search path but they need to be put there once C::B starts up in order to handle dependencies.