Contexts create subdivided "containers" within domains for objects with special needs (or in the case of objects that don't have special needs, the default context is used).
I am having trouble understanding how the ExecutionContext class relates to these contexts.
How are they related, or different, etc.?
ExecutionContext is a container for information related to the execution of a thread. So it's pretty much just a specialized context. It has a few neat properties, but they're likely not applicable to other kinds of contexts, which is okay since different contexts can have different uses.
From MSDN:
The ExecutionContext class provides a single container for all information relevant to a logical thread of execution. This includes security context, call context, and synchronization context.
The ExecutionContext class provides the functionality for user code to capture and transfer this context across user-defined asynchronous points. The common language runtime ensures that the ExecutionContext is consistently transferred across runtime-defined asynchronous points within the managed process.
An execution context is the managed equivalent of a COM apartment. Within an application domain, the entire execution context must be transferred whenever a thread is transferred. This situation occurs during transfers made by the Thread.Start method, most thread pool operations, and Windows Forms thread marshaling through the Windows message pump. It does not occur in unsafe thread pool operations (such as the UnsafeQueueUserWorkItem method), which do not transfer the compressed stack.
You can find out more information about the ExecutionContext at the link above.
