I totally agree and will keep my fingers crossed.
My application requirements are to dynamically load appropriate List and Detail Views in a runtime environment based on Role/Workflow driven navigation and security.
For example, a Requisition detail item becomes a PO detail item that will have one or more Receipts. Each Receipt item will have a GL transaction posting. When the AP invoice arrives, the system will automatically generate the Payable based on the Receipt. The resulting AP GL transactions will wash the Open Accural accounts. The appropriate view perspective is based on the workflow state and the Role (Executive, Inventory Control Clerk, Requisitioner, Purchasing Agent, etc.).
Based on the volume and complexity of Views, it makes sense to store them in a database. Doing this also makes BO changes a heck of a lot easier to deal with. Currently, I have to hand edit the XAFML for the non-default Views before I can Update the Model and get into the Designer again. Storing the Views in a database allows me to continue with the default views and later amend the Role/Workflow State Views.
XAF is, by far, the best toolset I've found to accomplish modern ERP requirements.
As I communicate with clients (internal and external) via prototypes, the BOs will change radically. When clients want to "have it their way," a prototype will quickly let them decide if kim chee and peanut butter are good together on their "burger." Discovery prototypes are usually much better (definately more profitable) than arguments with the clients. Especially when the client comes back with "their" own correct design.