No DeploymentCatalog hides those details. It allows you to create a MEF catalog from an secondary XAP but it is not a general purpose secondary XAP downloader. You could use the code that we had in Package in your own projects but MEF was trying to not be
in the business of providing general XAP downloading API's.

My case is very specific and I will be able adopting it to the latest MEF (SL4) without implications. We have an enterprise application (Winforms) that was integrated with SL3 frontend powered by Prism. The Application provides a UI output that is compiled
to a fully-fledged .xap package and deployed to the server so that clients can receive new modules dynamically. However Prism didn't allow us getting enough control over assemblies that are being loaded and processed. The generated classes were marked with
our custom attributes carrying some metadata to be processed on client side. I managed to rip the Package class from the MEF previews and reused its callbacks to do manual processing (like analyzing metadata and initializing modules from code with the notion
of role-based security, etc.). Everything worked perfect for my side.

Now we are moving to SL4 and migrating from Prism to MEF. Needless to say the efforts are reduced by 50-80% when using MEF in comparison to Prism. I'll be able marking auto-generated modules with custom Export attributes and getting both metadata and instance
discovery working perfect. I don't think I will have a need processing assemblies manually with MEF.