The general rule I would take from this, because it applies well beyond this framework: "keeping two pieces of state in sync" is always a design problem wearing a timing problem's clothes.
If B must always equal f(A), then B is not state. It is a view of A. Storing it separately creates a second source of truth and an obligation to maintain the relationship forever, and every bug you described is that obligation being violated somewhere.
The cases where people think they need a real copy, and what to do instead:
"It is expensive to compute." Derived values are cached and only recompute when their inputs change. This is already handled.
"The user can edit it, so it is not purely derived." Now it genuinely is state — but then it should be initialised once, not synced continuously. An effect that keeps overwriting the user's edit is a bug you will hit next.
"It comes from a request." Then the request is the effect, and what it produces is state. The derivation and the fetching are two different things and should be two different pieces of code.
That third one is the honest use of an effect, and it is worth noticing how narrow the legitimate list is. Most effects in a codebase are derived values that have not admitted it yet.