Code Junkie's comment also gets my vote.
Either that, or I'd like to see a version of the DirectoryPartCatalog which supports nesting of addins in child folders of the specified addin folder.
Given MEF's aim's of targetting composable applications, the current addin deployment support is not (IMO) sufficient. Potential naming collisions between addin assemblies and/or their assembly or other file dependencies means MEF really needs to support
nested folders for addins.
Without nesting, you can't really reliably support seperate deployment of addins. Which ends up meaning you are forced to package and deploy addins with the host app removing a primary benefit - the ability to install addins at a later data *after* installing
Admittedly you can kind of get around this right now by searching for subfolders of your addin directory and creating an aggregate catalog with a directory part catalog for each found subfolder. This is kind of messy though, and from what I can tell,
looks like it would result in loss of support for caching.
There are other deployment related issues which I'd like to see some attention paid to, some of which System.Addin covered - one is tool support for identifying and isolating contracts from implementations so that dependencies can be controlled and managed
Related to this, the ability to load Addins into a separate AppDomain is valuable for detecting and controlling dependencies.