Our policy on policy

... is that we don't want the platform making policy decisions.
In general, any time the platform makes an arbitrary policy decision, half of our clients will think it's the wrong one. This why we're trying to shift our architecture focus to enabling features instead of directly implementing them.

However, often making a policy decision lets us simplify some portion of the platform. After all, not choosing policy usually means:
1) add a bunch of knobs and flags to let users customize an operation. This is what we did with source-level step-in. Step-in is not well defined, because it's unclear where the step should complete. So we added a bunch of flags to the stepper to let the debugger specify what sort of things that stepper should stop in.  That means extra complexity in ICorDebug.
2) add an abstraction layer to let the users customize things. Just adding abstractions everywhere can really complicate a product. Making all your functions virtual is not the answer. It takes a lot of design skills to know which abstractions to add and how to slice the interface.

So there's a constant tension between keeping things simple and giving clients the flexibility they need.

We hope to get this better in V3 ICorDebug.