Is it as simple as that?

I guess I'd like to have a better understanding of the implications before making my vote. At this point, all I've heard is a little fact and a lot of opinion. And, since CLR isn't even a fact yet, I'm not sure how much actual fact there is.

From what I understand:

The CLR's role in .NET is to provide access to the underlying classes of .NET as though they were part of the CLR language. The .NET CLR languages are little more than scripting languages. They do little by themselves other than provide for variable declarations and control structures. The key ability is accessing services provided by the .NET foundation (although they are compiled).

Now, VFP as designed for v. 7 will have access to the .NET foundation through automation rather than as native classes. I'm not sure what the downsides of this are. But, if it does indeed have full access to the underlying foundation, why truncate VFP to make it into a scripting language when it currently is, in fact, a full DML?

If that move is taken (no macro substitution, no DML, no backwards compatibility), won't that hasten the demise of VFP?

Inquiring minds want to know!