Matt Pietrek noticed you can't detach while interop-debugging (aka "mixed-mode") in VS. Short answer: this is a limitation of the CLR / ICorDebug.
Longer answer follows...
Some history:Interop-debugging is managed + native debugging simultaneously in a single debugger. This means it's the lowest common denominator of managed and native debugging. Managed-debugging supports detach (ICorDebugProcess::Detach), but native debugging didn't support detach when the CLR was first written. DebugActiveProcessStop didn't come around until WinXp / Win2k03. So Interop-detach was prevented by the OS when we first wrote the CLR.
... so why didn't we add Interop-detach in Whidbey once the OS support was available?1. Interop-debugging involves ICorDebug wrapping all of the key native debugging APIs to make them play well with the CLR. The CLR does lots of evil things under the covers that would else wise horribly confuse a native debugger. This means that even when a new OS API is added (such as DebugActiveProcessStop), CLR may need to do some work to wrap it. This is not a good place to be, and we are actively working on fixing it.
2. We also ended up making various simplifying assumptions in interop-debugging that relied on not supporting detach (eg, that various race windows wouldn't exist), and so adding detach became sufficiently expensive that we couldn't just throw it in for free once we had the OS APIs.
3. We also had bigger fish to fry with interop-debugging. For .NET 2.0, we focused our attention here on radically improving stability (especially for attach) and performance.
4. Not enough demand from customers. Interop-detach was missing since the first Betas of VS2003 (around 2000 / 2001?), so people had plenty of time to loudly give us feedback about it. The customer feedback was for stability and perf, and so that's where we focused.
Thus we never added a feature request to the CLR to enable it even once it was technically possible from the OS.