Indeed, as there's no boundary cross except for the CBO inheritance. All
managed and no context switch at all.

This information is really available on msdn, it is a shame this library is
nearly unusable if you don't have it locally on your computer! And also,
google is your friend. But it's always a pleasure to help. Take my words
with caution though, I didn't write the system and can only rely on what
I've seen and read on the subject.

The process is a bit complex, but still manageable.

For IIS5:
When an HTTP request comes in, it is processed by IIS (inetinfo.exe). As
.net is implemented as an ISAPI extension, it then goes through
ASPNET_ISAPI.dll, hosted directly in inetinfo.exe. It then try to see if
aspnet_wp.exe is loaded, if not it loads it, and then establish a named pipe
and sends all the data through it. ASPNET_WP.exe is the only one dealing
with managed code.

Isolation in .net code works through several AppDomains hosted in ASPNET_WP.
The isolation mode configured in IIS metabase is where an ISAPI dll is
loaded in dllHost as a separate process. As you see, if the isapi extension
is loaded externally, it will still forward to the aspnet worker process. If
you will, isolation mode is dead :)

As for IIS6, the kernel mode http extension (http.sys i believe) receives
the HTTP request directly, and have its own cache. In the case of graphics
and html files, it can very efficiently stream directly from the file system
to the network card without any overhead, as there's no context switch to
get back to user mode to go to either inetinfo.exe or aspnet_wp.exe. If it
does not have the cache, it will then forward to w3wp.exe directly,
circumventing inetinfo.exe. MSDN mentions that it is passed directly from
kernel mode, but in fact it does context switch in user mode to go to the
worker process.
IIS6 supports "application pools", where you can set high isolation. In this
case, instead of having one process with one AppDomain per application, and
AppDomains only being recycled, high isolation provides several instances of
w3wp.exe, each containing one AppDomain per application in the same
application pool. This gives you a very powerfull way to recycle your
processes and provide isolations on a "pool" basis, and is much more
granular than either the asp mode or IIS5 worker process mode.
Note that aspnet_wp.exe is replaced by w3wp.exe only if you don't use the
IIS5 compatible mode. If you do, you'll use the old aspnet_wp.exe and won't
be able to use application pools for .net.

It's not really cryptic. There is a big misunderstanding about the COM+
support in .net, and it's often mistaken for COM Interop support.
COM+ uses the remoting proxy feature to provide for several proxies, each
responsible for managing communication between different components. It's
all managed code that taps into the COM+ context model nearly natively (as
it's written in managed c++). The overhead is very very low. The only moment
where you do real interop is when you remote across computer boundaries, in
which case you go through DCOM. You do suffer some performance problems, but
once again, performance doesn't matter at all in a distributed architecture,
throughput does, so it's quite negligeable.