On the other hand, the whole point of normalization in databases is to avoid redundancy and have "single source of truth".
I find the concepts of normalization and denormalization applicable and helpful outside databases as well, though a different terminology is often used.
I know this is overly philosophical, and in practical scenarios we readily (although not always unambiguously) differentiate between "cache" and "state", but the point about transitions and that being a major source of bugs still stands.
If you want to unify state and cache, you might want to go down a different route:
Think of log based filesystems (or a log based data base).
Instead of defining your operations in terms of state, you define them as pure functions of the log.
So your log is full of operations. Writing just means appending a symbolic operation like `write(key, value)` to your log.
And you define the result of `read(key)`: scan backwards through the log until you hit the last instance of `write(x, value)` and the return that `value`.
Now state means: compact your log by replacing a swath of `write` log entries with one big `snapshot` operation that encompasses many key/value pairs.
Alternatively, you can also define state to mean caching your `read` operations.
In this approach, it's no coincidence that the log is a data structure that has a linear shape: the evolution of state over time is also linear.
(With some cleverness you can replace the linear structure with eg a DAG; and then also think about how you merge divergent states.)
And the problem with state is that you have to make sure all your state transitions don't cause bugs. What we know as a "cache" is essentially creating new state representing existing state, with all new transitions...