The server and client should be OSGi containers. This would give many plugin related features for free if plugins were created as OSGi bundles.
This proposal is for using OSGi as an the plugin system for Minecraft. A Minecraft plugin would then be an OSGi bundle that uses the Minecraft API to access the Minecraft implementation (which would also be an OSGi bundle). Instead of spending time reinventing the wheel, Mojang developers could focus on the Minecraft specific aspects of the API.
Justification and Use Case:
Alice releases a new version of her admin mod. It has a new command that Chuck wants to use on his server so he opens the web console for his server and chooses to update that plugin. The old version is unloaded then the OSGi container downloads, verifies, and loads the new version. None of Chuck's players had to reconnect because the server didn't restart.
OSGi plugins (bundles) can be dynamically loaded and unloaded. There are many command-line and web based administration utilities already available that could be used out-of-the-box for a Minecraft server running in an OSGi container.
Doug wants to play on Chuck's server, but Chuck's server is running a plugin that requires a client-side companion plugin. When the client connects to the server, the server sends the URL of the client-side plugin. The client then downloads the plugin and checks that it has been signed by Mojang. It then loads the plugin in a sandbox that only allows it to access the client-side API.
Some OSGi containers are light-weight enough to run on the client side. Here, the security features of the OSGi specification provide both coarse (signed bundles) and fine-grained permissions. An example from a permissions.perm file: ("java.io.FilePermission", "<application_path>/-", "read,write").
Alice's plugin has a dependency on a third party library, say Guava 10. Bob's plugin has a similar, but incompatible dependency: Guava 13. If Chuck tries to load both Alice's and Bob's plugin on his server bad things could happen. In this case, Bob's plugin might throw a MethodNotFoundException for Objects.ToStringHelper#addValue, which is binary incompatible between Guava 10 and 13 (this is a problem I ran into personally using Bukkit.) Luckily, Chuck's server is running in an OSGi container and he can happily enjoy the features of both plugins without dependency clashes.
With OSGi's classloader isolation, each plugin can load it's own incompatible dependencies while sharing compatible ones. A plugin developer could, for example, specify that his or her plugin requires some version of Guava between 11 and 13.
There is an additional burden on plugin developers if they want to make their plugins dynamically load, unload, or update. A method for marking plugins as "not dynamic" could mitigate this. You could only get that feature if you want to support it.