Hi, good to start the discussion somewhere in text 
Im all in for having a concept to allow faster simpler content editing and eventually real prototyping making word or markdown writing obsolete. I wrote down a few thoughts myself and i think down the road my thoughts went more into the direction of this being impossible. Let not get discouraged by that … we’ll find a way right?
Implications on caching and cache-invalidation
While implementing caching for the component engine I noticed how thought out the current structure is after all. Currently the document node has a root cache entry which is flushed if the node or any of its parents change. This covers changes to the title for example. But the content in form of the content nodes is by convention cached via its content collection. Each content collection e.g. “main” is flushed for all descendant node changes. In this regard it’s important that the document has a content collection node where the actual child-nodes live as if they are directly on the document level the cache flushing would not work the way it does.
I assume that content nodes as json blob will directly be cached with the document and thus always invalidated if title changes or content. That is greatly simplified and with less nodes being used we probably wont need fine grained cache handling for content nodes after all?
Working multi dimensional content
Neos offers with Neos 9.0 a well distilled variation concept. Most used are either fallback dimensions or real separated (peer) dimensions.
I believe we still have to solve keeping content in sync for peer dimensions. Because i wouldn’t want to make german a fallback of english, just to have the same content. Instead i would seek to create a page first in any of the peer languages and have it translated to all other parts. Now editing the content in any of the peer variants might lead to the content from going out of sync. To avoid this each new content node would need to be translated as well into the other languages as well as changes to the text. → This is not solved but the ui could provide tooling to translate new content nodes individually and also retranslate them.
The actual problem is when the content differs greatly in structure over the peer document variant. This can have various reasons. And the sole reason is that redactors don’t mind the IDENTITY of a node but only see it for which content it has. So the structure can greatly vary but the actual content might be closely the same. When we think about editing we want to work with nodes on the page as easily as possible.
- Editors might copy a node and experiment with the content and properties and later remove the original one. Intentionally or not but this changes identities.
- Editors might want to split text nodes to insert a node in between. The structure greatly differs and a new node with new identity was added while the content is roughly the same. Worse deleting the node in the middle will lead to the same content with a different structure / identities.
- Editors might need to remove duplicate content after collaboration and merging workspaces, possibly removing a node which exists in another language but not the duplicate that only resides in the one language
These cases are just from the top of my head. And they are a problem today and prevent us from working more loosely with nodes as we do care about the identity after all? Or dont we? As a technical person i can see to edit my own side in a “correct” manner regarding identities of content nodes.
If the json blobs of document content nodes also require an identity i don’t think this improve our situation. Worse without the separate node and identity handling we loose working collaboration:
Reviewing content / Working with multiple workspaces
Storing the content in form of separate nodes allows for publication of individual changes. And a similar well working merge when changes are performed across multiple workspaces on the same page. This is handled by the content repository core and well tested. Even with Neos 9 we only started to make collaboration really work on the same node. Working with nested content (see accordion or columns) under these condition with json blobs will be super complex to solve properly - if not exactly as complex as how the whole content repository is already. Just imagine content deletions in one part where elsewhere new content is just being created inside a content element.