@dcuccia: In fact, the hardest part was working with a moving target, i.e. .NET Framework 4.5 Beta, RC, and internal interim builds, while developing Rx v2.0. If we'd only start now, with the final bits of .NET 4.5 and Portable Library support, it wouldn't be as hard.
The main thing to decide is what you want to do with platform-specific functionality that ended up in a bottom layer of your library: keep the API surface there, discover it at runtime, and mark it deprecated to stimulate new usage patterns; or have a clean slate release for Portable Library with migration guidance for the types/members that moves. (In fact, if you don't have to slice a type because it had both platform neutral and platform-specific stuff in it, you can simply move the type up the layer map.) As explained, we went with the second approach initially, but the benefits diminished as we went along, simply because Portable Library's intersection between our target platforms got much better by RTM.
If I'd be doing it again now, I'd really strive for a portable core that eliminates platform-specific copies right from the start. Based on what falls out of the intersection, I'd decide whether some kind of enlightenment mechanism is required / warranted or not.
To implement such an enlightenment mechanism, the main trick is Type.GetType(string, bool) to look for a known type in a known assembly (ideally demanding an exact version match, saving you from future headaches) implementing a known interface. Then decide whether you can do a graceful fallback if the module is missing. At the same time, try making all deployment vehicles such that the enlightenment assembly is always installed (e.g. as part of a NuGet package, or in an Extension SDK).
I'll chat with the Portable Library team about documentation and guidance plans.
Hope this helps,