our plugins are specialised because otherwise we would have more performance problems - it is expensive to load all plugins into memory to find out what plugin supports which feature. Once we have some mechanism to cache plugin features we can add more hooks all over the place. Subplugin support is problematic - naming, performance, AMOS, etc. I believe renderers are a separate topic.
Removing of features is imo not an option, for backwards compatibility we need to keep all plugin types.
I believe that admin/tool was a success, we need to migrate more stuff from admin/ there such as site registration. I designed the local plugin support for ''hacks'' that were not supposed to be part of official distribution, place where standard rules do not apply. The only major problem I see now is language packs in AMOS - they need to have unique name which was not required in older versions, the plugin database is good for name reservation, forbidding local plugin uploads would break translation workflows.
I already proposed to add cohort contexts, I do not understand why there should be any other context type or how it could be used.
One general plugin would be nice, but so would be standard CamelCase for classes, request routing, class loading - pretty much exactly what Symfony2 does. Maybe the new plugin type could define a completely new API and modern coding style...
I vote for B/