This is exactly why 2-way data binding fell out of favor in modern UI development. Describing the problem as "the cardinality of the state of the system extremely large" is a succinct way of putting it. The non-linear increase in possible state quickly makes testing an uphill battle. And it's over when you can't have a comprehensive testing strategy, forget about it.

Can this be mitigated by ensuring that historical/legacy events are all transformed to more modern equivalents? Similar in theory to https://stripe.com/blog/api-versioning ? Then you at least have a chain of testable transformations and a reduced cardinality for the actual interactions that reflects the cardinality of all the ways your business users actually use your product today.

Of course, this can be lossy, but is it any more lossy than the non-event-sourced CRUD system which is essentially transforming historical events into "overwrite these fields" events that can only be used for their original purpose?

To me, the reason not to use event sourcing is more that the tooling and developer experience is just really poor - and so decisions like the above, while valuable to think through directly, rapidly become overwhelming. Visualizations of system state are only as good as the code you bring yourself. I'm hopeful that people building tools on top of things like https://materialize.com will start to change this though!

This is why I always like to have a `status_history` or `audit` table. You don't have to have event sourcing to still want a trail of who changed what in the system when.