I'm not expecting you to reply, even though you say you will. ;-)

In a nutshell: dotNET is better than VFP at quite a few things, including some implementation options. You've sought to turn 4 of those into requirements.

But if VFP has its own way of solving the *business problem*, and if the VFP way stacks up against the dotNET-oriented implementation, that's important. If the VFP version meets the challenge to be "faster, more scalable, more reliable, more robust, easier to maintain, and in less time" than the dotNET version, that's important too, even if it doesn't use your preferred implementation. Equally, if the VFP version is a trick-shot or hack, that's very useful information too. Lets not block it with rules.

As for dotNET data: it isn't just about LINQ. MS has stated right here on UT that getting VFP's autospanning local datasets into dotNET is a priority. IMHO that's crucial. That opens up a whole set of new implementation options for dotNET. I know you're not a betting man, but I'd happily wager that when dotNET people open an indexed large lookup locally for the first time and realize it is autospanning without hogging resource, we'll see excited developers who are absolutely gobsmacked at the potential.