A long standing problem with Microsoft's implementation of the CLR is that only one can be loaded into a process at a time. With Silverlight, that will no longer be a problem.
The CLR/Process problem can best be illustrated with extendable applications like Outlook. Outlook is a native application, which effectively means it isn't tied to a specific version of the .NET runtime. If the runtime isn't already loaded, then whatever version of the CLR used to compile an add-in is loaded into memory.
The problems start when someone wants to load two add-ins that were built using different versions of the CLR. If the newer version is loaded first, the older add-in may have compatibility issues. If the older version is loaded first, the newer one will simply fail outright.
This becomes an especially big problem with applications like Internet Explorer, which may encounter many add-ins that are never loaded in the same order twice.
To address this, changes were made to allow multiple versions of Silverlight's CLR to be loaded into the same process. This doesn't fix the problem for older CLRs, though a single 'legacy' CLR can run side by side with multiple Silverlight CLRs.
Jason Zander has more details on his blog.