I think you are right on the track, but I do not know if those two reasons (porting to multiple platforms and not having to install the runtime) will justify making VFP CLS compliant. I would encourage everyone to read what becoming CLS compliant would mean. I apologize if this has been rehashed here, but let's look at it from what other languages gain/lose:

C++ gains by simplifying development. Any developer writing COM components using C++ had to constantly duplicate code to handle the reference counting in COM (AddRef and Release methods). C++ developers also had to handle memory management in applications where it was unnecessary to tweak every last ounce of the application. For C++ developers, .NET removes the need to do this in every applications. C++ objects can get garbage collected by the CLR, thus removing the need for reference counting and memory management. C++ is in a special situation though because it is an ISO standard, so MS could not change the language, it could only extend it. This is the reason why C++ has the ability to live in an unmanaged world and a managed world.

VB gains a tremendous from moving to .NET. VB finally gains the object orientation that developers has requested for a long time (implementation inheritence, overloading, etc). It gains in performance (hopefully). It moves to a more robust form and eventing model. It gains a cleaner error handling mechanism through exceptions. Another nice thing that VB gets by the fact that backward compatability was not an objective is that the language could be cleaned up - removing things like SET, GOSUB, Form.Load, etc. Personally I do not think they have gone far enough in the cleanup though.

By cleaning up VB and extending it, VB will be at a point that Fox was in the conversion from Fox to VFP, but there were enough reasons to move VB to be CLS compliant.

From the VFP perspective, I do not see VFP gaining as much. It would be an interesting task to map the current VFP functionality to CLS. My guess is that most of the OOP language would be mappable to constructs in the CLS. It is also my guess that the xbase side of VFP would not map directly into the CLS. I would also suspect that all of the VFP controls and form will need to be rewritten or VFP would gain the Win Form model. So, in the worst case, would you want to use just the OOP aspects of VFP to write applications along with Win Forms and ADO+ (instead of the xbase within VFP)?

In the best case, if MS can move the entire syntax to be CLS compliant the things you would gain are:
1. Support for the language in ASP+
2. Code interoperability (being able to subclass VB classes in VFP and vice versa.)
3. Code portability (if MS and its partners [Corel for one] can move the CLR to other platforms.
4. Removing the need to register components (.Net assembilies are not registered, there meta data is stored within XML in the manifest of an assembly).
5. Overloading
6. Type safety
7. Free threading
8. Exception handling
9. ...

I encourage everyone to add to this list because this is the only way that we can convince MS to move VFP to be CLS compliant. I would question the paradigm of living in both worlds because it would almost be 2 different languages - a pure OOP language (minus macro expansion, etc and gaining type safety, overloading, etc) and the current VFP language (xbase and current OOP model)

Are these additions enough to justify an upgrade similar to the port from Fox to VFP? You tell me.

Just my 2 cents.
--Matthew