I don't think putting VFP into the CLR would be very beneficial at all. In reality, I think that would be the ultimate death of the product. Sure, there might be a language called VFP or VFP.NET, but it would actually bear little resemblance to VFP as we know it today. We'd spend so much time learning what's there and what isn't and how to use the .NET equivalents for what's not there that'd we just be better off learning C# to begin with. If you go the other way and say that the CLR should be expanded to support all of what VFP does, then VFP loses its niche and is just another language in the CLR. Also, if VFP syntax support is added to the CLR, then .NET has sort of lost direction. Now you have syntax that let's you work against data in cursors instead of using stateless objects like ADO+.

Keep in mind that VS.NET is a framework and the framework is attempting to tell you how to build applications according to the MS vision of how applications should be built. If features are added to VS.NET that don't fit with this vision, then this message becomes unclear. That's one of the reasons I like C# so much, it's new and tailored to the vision and doesn't carry forward any old baggage.

If we could have both, IOW, VFP continues along the same course it's been on since MS got their hands on it (from a technical standpoint) and we got VFP.NET which was a CLR version of VFP that just supported what the CLR can handle, then that would be interesting. Unfortunately, if we got VFP.NET, I think development of regular VFP would stop just like it has for VB.