Thoughts
Here's another LSFA sketch:
You have React components that are pure on their inputs that describe the UI. Normally React state is used to store anything that can cause a re-render; in LSFA React state would only be used to store information that *only* effects UI (for example, screen width). Basically, very very little.
Pages would be divided into Islands (borrowing the term from Fresh without having ever used Fresh). Each Island would have state. The rule of thumb would be that an island does not care about how it is rendered. Islands exist on both the frontend and backend (unlike React components which are frontend only). Islands store all of the state that is needed to render them (field data, etc). When updating an Island's state from the frontend, the Island is re-rendered locally and then the update is sent to backend where the Island state is updated in the database (a noSQL key->document store). On the backend, the Island could implement additional verification checks (e.g. username already taken), it could define uniqueness keys (e.g. two different users need different Islands for the login page, but they want a document they're collaborating on to be backed by the same Island instance), and it could even define a lifetime (e.g. 30 days or persistent) if you were worried about clogging the database with half-filled-in login forms.
I think this works well for rendering. The limitation of clustering state is how many developers (including myself) use React anyways. Database persistence of this state offers so many advantages (see the other LSFA posts, but in short: ability for the user to reload without losing work, client-side validation of errors without needing dedicated async JS fetch code, the content needed to load the page available at page load).
The issue is you've fragmented the backend data. Either you use the LSFA database as your only database and write backend code that people aren't used to writing to populate a number of different sources of truth for different pages, or you use the LSFA database, almost as a cache, in addition to your primary authoritative database. The second sounds viable to me. It also kind of sounds nightmarish, don't get me wrong, but if the LSFA framework was built for it and handled that database automatically, it wouldn't be worse than React + a traditional database.
I think what you need is pointers. If the LFSA database was able to store "pointers" to other documents in the form of abbreviated queries, well your complexity would explode and it would be hidden so it would be a nightmare, but it would let me do what I want to do. I think it would work. I just need a database.
Earlier versions of LFSA considered including SSR and/or object diffing as a core feature—this version includes neither (although it could easily be extended with either).