They are obviously not commited to actually coding the new OS features in pure managed code (probably due to time constraints, and problems that arise which they already know how to solve in unmanaged situations) ... but they are commited to providing a .NET API to the entire API. It may not work out that way (time constraints and all), but the MS goal that has not wavered is that a programmer should be able to write a 100% managed .NET program for Windows Vistas native library, and have access to every OS feature they could need (obviously you won't have access to every feature in cases where the new API replaces an old, they are highly unlikely to provide .NET access to the older depricated API) ...

For instance their Managed DirectX initiative shows how they most likely intend to do this ... an API that is by its nature unmanaged, but going forward with an eye towards managed clients.

It is not just that they have backed up due to cost or other reasons either ... part of it has to do with client demands - The .NET comminitity can and does consume COM objects all the time, and provide wrappers around C APIs very easily - the COM and C communities do not however have similar ease of translation from APIs that would be built using advanced .NET features (reflection anyone?).

So the only way MS can really please everyone is to provide the dual access system - whichever way they implement the internals.