InDesign DOM Redesign and Redevelopment. I beg of you.

Question

The architecture of InDesign's Document-object Model handling has always perplexed me.  What should be a simple, straight-forward hierarchy of parent-to-child cascading style control is instead a haphazard peer-to-peer asynchronous spaghettibowl—a wonderful tribute to Pastafarians worldwide, yes, but hardly a good-working model for production of publications.
I understand that when InDesign was being developed, Adobe did not yet hold a marketplace stronghold against competitors like Quark Xpress, and a seamless user experience between applications was key to get people to switch from one to the other. But it seems by doing so, Adobe shot itself in the developmental foot. Either that or there was simply no master plan for an overall framework for document object modelling.
It's because of this that I really propose Adobe come up with a new structure. But how to do it without bricking the many tens of thousands of *.indd files out there? How to transition without destroying what's already been built? It's much like the 710 freeway in South Pasadena: finishing a simple gap of highway that would enable the entire system to flow better would essentially have to destroy an entire community of homes established over 50 years. Yet without it, things are a mess. InDesign 5 files are already incompatible with previous files, so I don't see too much harm in bricking them again.
To illustrate my point, and the urgency, let me bring up the issue of Master Text Frames.  Anyone who's been using InDesign since the turn of the century has always seen the 'Master Text Frame' option on the 'New Document' window, hanging there pointlessly like a coccyx.  The reason for its existance has been the subject of much debate by several critiques ranging from independent design journalists to Lynda tutorial videos. Even though you can perform the same function by simply creating a text autoflow on a master page, it's still there as an option. And, as far as I know, it's an option impossible to toggle it any other menu-based means once the document has been created. This demonstrates that the feature's original purpose (as well-intended as it might have been originally) has been deprecated in the scheme of a bigger picture that's developed since then. We now have book files, template files, multiple masters, XML support, etc, etc... InDesign's original concept was all laid out during a period in history where we were transitioning out of the "Windows 98" peer-to-peer mindset of the 90's before returning to the time-tested server-client system. It's just better than peer-to-peer for not only internal networking but design structure.
If that doesn't convince you, let me ask a question: Suppose I wanted to apply a template file (or better yet, elements of one) into an existing InDesign document? Sounds crazy I know, but we do this all the time in the web design world. So imagine if instead of master pages being embedded within documents, they were actually external template files like *.css, with stylesheets and scripts built into them? And like web structures, imagine that they controlled things from a top-down hierarchy to all the styles in all child documents of all book files?
ie:
indt > indb > indd.
Simple.
Master object/paragraph/character styles and libraries (and any other attribute you can think of) would be defined in the master document templates. From there. In book file, you would choose which template masters you wish to be associated with that book, and this selection of templates would carry down to the connected child documents. Finally, the child documents would inheirit these styles or could have their own embedded styles which would override the master styles, if desired.
Now that I think of it, with this structure, indd files themselves would not even need to be touched for those people who don't want/need whole books. So mabye bricking things is unecessary.
Compared to the peer-to-peer chicken-or-the-egg manual syncroninzation scheme in the indb pallete, it would be a simple automatic system ensuring uniformity among all involved documents in the book! And these template files, since external, could be used for many book files, automatically updating all of them. And we would never have to deal with the dreaded "UGH! Why is this style folder resyncing itself in a different order, and why did that style reappear when I just erased it!?" syndrome forevermore.
InCopy could really become a truly useful application if done this way rather than a cheaper watered-down version of InDesign for editors. You could have a good chain of command between designer, editor, and typesetter. And it would be one step closer to seamless integration between print and web. If a better DOM manages to be produced, I have a feeling InCopy is going to go by the wayside, much like ImageReady.
So yes, I urge that a serious redesigning and redevelopment of InDesign's style / object hierarchy be looked at, for the sake of humanity!  I'm sure I'm not the first one who has thought of this. It just takes an executive decision somewhere in San Jose. Here's hoping. Cheers.

Answer 1

I think you misunderstand what a Book (.indb) file is. It's a collection of documents. It's not based on any template and it has no  attributes to speak of other than a list of pointers to the component documents and a record of pagination (maybe).
Yes, I noted that.. the indb books wouldn't hold the styles within them. It would only pass them from template to document collections.
Styles, swatches, master pages and pagination can be synchronized across the book, or not, as you decide.
Yes. That wouldn't be interfered with. You can still embed styles within documents, or have them passed down from templates. Like I said, what I'm proposing is only a way to feed styles top-down from templates. The way things work now, a template disconnects from the document the moment you load it. I'm saying it should retain its connection as a master page.
What I'm really proposing is the disengaging of embedded master pages and allow links for external master pages. Might as well make those the templates since we already have them.