That's great about the possibility of a DDT API.
Of course there is one huge advantage in working in VFP when using live metadata: we embed the key tables in the EXE, and use SEEK against them (typically once per control, putting the field record object on the control for later use). It is very fast. I haven't seen a need to have changeable metadata on a user site, but I know others have, and in those instances the EXE can be built without them (losing about 15% in speed of the DD seeks, but still acceptable).
Most importantly to me, building the app using metadata is the key to managing complexity. From our perspective, Business Rules, both data and UI, belong in metadata, not buried in an application. When I want to change attributes for a field throughout the app, I change the Domain (which I created in xCase) attributes used by that field, regenerate the Database and the Data Dictionary, and it changes everywhere in the application (the controls being subclassed to respond to metadata regarding width; and the builders we created being capable of sorting through a design surface and resizing controls to what is in the metadata, to handle placement issues).
In the online classes (now all videos) for using our stuff, I start off the first session with challenging developers to "use your head, not your fingers" in developing software. Metadata, and associated tools, remove about 80% of coding from an application, leaving for the most part the interesting stuff that's fun to do. Not including documentation, although David Le Mesurier has created a tool that uses the metadata-stored help information, takes a screen shot of a design surface, and puts the the two together into a West Wind Help Builder topic, broken out by the controls on the design surface with the metadata-stored help information. It can actually hit all the design surfaces on a form automatically.
Now, it may be that in .Net it makes more sense to stuff things into assemblies built around each BO. Especially since Orcas apparently won't have real local data storage, based on what I've read from Rick Strahl. With a little development-mode management of what entities have changed, that may be the quickest way to help Pertti (and myself) out of the burden of typing for living. <s> Heck, DTE programming can't be that hard, right? (I think it fits somewhere between Dante's 3rd and 4th levels, where one is condemned to writing CTYPE casts all day...)
Anyway, I think that extending the DDT into an extensible, fully integrated tool at development and runtime would give SF that product distinction which (marketing people say) every successful product has.