I wouldn't life a finger to get VFP UI if I have .net available, but being able to reuse some middle tier trick will be great.

I guess that's the point: it won't be a VFP UI. It'll be winforms or wpf or whatever. The VFP source is just grist to the framework compiler. Scripts, if you like. I don't believe that any reported UI deficiencies of VFP are relevant if we're getting 100% managed IL output or compiled dlls.

I agree re your second issue. Everything I do these days is middleware. We're pushing west wind hard and it might be nice to experiment with properly threaded NET stuff without having to rewrite.

I still want to know everything I can about .NET and I like the stuff Microfour has done with data handling as it is very familiar after working with objectified data for 10 years in VFE.

Fair enough wanting to learn about NET. As for the rest: you've moved some way into NET relying on a framework whose data mechanisms are familiar to you. ETC might be considered a framework with mechanisms that are familiar to you. The only real difference is the "VFP" label used to automatically downgrade ETC and the level of "real life" availability that isn't there yet for ETC. But nor is the EF there yet, and there has been no shortage of people singing its praises.