Enable vs. Implement

There's a key distinction between a platform (like the CLR debugging services) enabling a scenario instead of actually implementing the scenario.

Implementing a scenario means we provide specific functionality for a scenario. For example, the CLR debugging services provide explicit breakpoints and steppers.

Enabling a scenario means we're crafted in such a way that a client can build the scenario with the building blocks we provide; even though we don't provide a building block specific to their scenario.  Some examples with Visual Studio's debugger include:
- tracepoints, which VS builds with a fancy combination of breakpoints and inspection.
- Visualizers, which VS builds with func-eval.
- remote-debugging. ICorDebug enables this by making sure that we don't pop up any UI, such as an error dialog. If we did, that dialog would be on the (user's) remote machine.

Implementing can be nice for clients because it means the platform does more work which generally means the clients can do less work. For example, MDbg's has very little work to do to make stepping work.
Enabling means the platform does less work and so the clients may have more work to do. But that also means that the clients have much more room to innovate and do new things. This is particularly significant because the client may wish to ship more often than the platform.

When designing a platform, you want to enable as many scenarios as possible. Enabling scenarios without requiring significant additional abstractions means picking the right building blocks, and that can be a great architectural challenge.

This "Enable" vs. "Implement" distinction will become ever more significant in CLR 3.0 because we plan to re-architect to enable many new features without actually implementing them.