>First: real hard-core OOP.

You have to remember one thing: when M$ did port FPW (which was just a FPD application in a Window mask) into a real Windows application (Visual FoxPro), they did a rewrite. This gave us OOP. VB didn't get a rewrite and won't get one without possibly major incompatibilities issues. So they probably won't get real OOP in a near future.

BTW, I was told that the kernel code of VB was such a mess, that trying to add something as complex as inheritence to it was nearly impossible.

>Next: real data handling commands such as REPLACE, SCAN, and their related concepts such as Scope resolution.

VB is *not* a database application.

>Third, anything I can do at the current command window.

Would be nice.

>Fourth, a significantly enriched event list, a union of VB's and VFP's would be quite nice.

Agree

>The real question is, what about ADO vs. VFP tables? If VB could do anything VFP did (and I mean it-anything), but without native support for VFP tables (insisting on ADO objects instead), who would give up the fight and start developing in VB?

But then, why not use VFP wich have the feature you want incorporated in VB in the first place? You can use ADO with VFP also.