Adrian Bateman pointed me towards this great article on EnterpriseServices. It covers a lot of details, although it doesn't fully answer my questions. I wanted, however, to point out one part of the document I think is particularly dangerous. It reads:
"When the root object gets created, the associated unmanaged context is created and associated with the current thread. When a call to the child objects is made, since they are not associated with an unmanaged context, no COM+ context change is needed, hence the thread still maintains the roots unmanaged context id. When a child object calls on resource managers, the resource managers will in turn extract the unmanaged context from the thread executing the child object, which is the root objects unmanaged context. Relying on this is dangerous and in future versions the unmanaged context may merge with the managed context and therefore the child objects will be associated with a potentially different managed context; the resource managers will not pick up the root objects context. Therefore, upgrading to a new version of .NET could break code that depends on this type of behavior.
"
The implications of the last part of this paragraph are huge, and if that ever happened, my opinion would be that it would seriously hinder EnterpriseServices in .NET, and make it much more complex and problematic to use. In other words, I most definitely would not like having to make almost all my classes ServicedComponent-derived.
There's hope, however. A couple of weeks ago, a discussion on this topic popped up on the microsoft.public.dotnet.framework.component_services newsgroup, where Craig Critchley, from MS, talked about this topic. You can read the relevant comments here, here and here. His answers also helped answer some of my questions (although I think I don't fully understand what's going on, yet).
