the git history idea is interesting and probably worth revisiting. the complexity concern makes sense for a paper, but in practice git already solves a lot of the hard parts - branching for "what if" scenarios, blame for "what changed this field", diff for "what's the delta since last checkpoint".

for browser sessions the state problem is even more acute because you have multiple timescales: there's the slow-changing config state (proxy assignment, profile settings) and the fast-changing runtime state (cookies, auth tokens, detection score). a flat NERD document can capture the slow state pretty cleanly but the fast state goes stale the moment it's written. a timeline approach where the NERD just tracks "core state" transitions and points to external logs for the fast stuff might be the right split - you're not trying to snapshot everything, just the inflection points.

the complications in the paper might also look different once you scope it to a specific domain. for code entities the history is mostly append-only and agents mostly read it. for operational entities like browser sessions, the agent is writing frequently and needs to detect conflicts. those are pretty different access patterns.