You know, I have actually been thinking about this one a lot. The morphdom/template-based diff approach the engine takes is directly upstream of what I think is LiveView’s biggest design flaw: poor composition. LiveComponents don’t compose, lifecycle hooks don’t compose, JS hooks don’t compose, etc. Keyed :for almost didn’t compose and the fact that it took Jose and Steffen (both of whom obviously know what they’re doing) something like 50 commits to make it work is evidence to me that the underlying engine is just designed wrong.
At this point I do think there is a path. I haven’t nailed it down exactly yet but I’m pretty sure if you do element-level diffs on the tree (as opposed to dynamic/static splitting the text), assign ids to components, and keep an id => dom ref mapping on the client you can do a React-style diff across the network.
The messiest bit is that React encodes the diffs into the tree in such a way that the childrens’ diffs can reference the parent. Like, the diff is computed during a time-sliced rendering pass and then during the commit pass, once the child is being diffed in the actual dom, the parent’s dom ref is already available. But it wasn’t available during rendering. This indicates that the diffs themselves actually have to be tree-shaped, which I found weird and unintuitive at first.
(It also means that deletes are handled by deleting the parent element in the DOM with no regard for its children, which is a funny hack that having a tree-shaped DOM allows for.)
So I think sending down tree-shaped element-level diffs rooted in a known component is enough to build a better diff engine. At some point I will sit down and try to implement it and we’ll find out 
Another interesting note is that this would require a VDOM on the server, which seems reasonable to me as it would also make the diffs on the wire smaller. Though again the main benefit would be ditching the global keys and enabling proper composition.
