@djr: first of all, welcome to the forum! Very interesting first post you've got there
I may be the wrong person to comment on this, as I haven't had much time to think about these kind of changes (too busy building stuff on ProcessWire to spend time thinking what to change about it, I guess) but your idea made me wonder ..
how could selectors work properly with such a structure (not knowing for sure that a specific field behaves same in different places sounds like a problem) and what kind of effect would it have to scalability and performance (I'd imagine this leading to tables with hundreds of thousands or millions of rows quite easily, which could become an issue considering overall speed, indexes etc.)
Current database structure works quite well in both respects, so this is definitely something that would have to be considered carefully. Other than that, I'm actually not entirely sure that we're on the same page here about some of the things you've mentioned in your post:
You mentioned that this way fields wouldn't "have to be global constructs", yet I see that as a good thing. Reusable fields rather than page-specific ones.
I'm not entirely sure that I'd prefer to have field schema on the disk, even if it makes duplicating that schema in another installation in some ways easier.
One of the key strengths about ProcessWire, in my use cases, is that I can very rapidly build new data structures with the admin tools it provides. How well would that be in line with having that structure as files on disk, I wonder? They're definitely not mutually exclusive things, but don't seem to fit that well together either (though perhaps it's just that I can't see it yet!)
Anyway, interesting idea and definitely a good thought provoker