The principle purpose of MEF is extensibility; to serve as a ‘plug-in’ framework for when the author of the application and the author of the plug-in (extension) are different and have no particular knowledge of each other beyond a published interface (contract) library.
Another problem space MEF addresses that’s different from the usual IoC suspects, and one of MEFs strengths, is [extension] discovery. It has a lot of, well, extensible discovery mechanisms that operate on metadata you can associate with extensions. From the MEF CodePlex site:
“MEF allows tagging extensions with additonal metadata which facilitates rich querying and filtering”
Combined with an ability to delay-load tagged extensions, being able to interrogate extension metadata prior to loading opens the door to a slew of interesting scenarios and substantially enables capabilities such as [plug-in] versioning.
MEF also has ‘Contract Adapters’ which allow extensions to be ‘adapted’ or ‘transformed’ (from type > to type) with complete control over the details of those transforms. Contract Adapters open up another creative front relative to just what ‘discovery’ means and entails.
Again, MEFs ‘intent’ is tightly focused on anonymous plug-in extensibility, something that very much differentiates it from other IoC containers. So while MEF can be used for composition, that’s merely a small intersection of its capabilities relative to other IoCs, with which I suspect we’ll be seeing a lot of incestuous interplay going forward.