I feel you, but isn't the state of truth for most websites supposed to be whatever is in the database? The example TODO List app, each TODO item has stuff in it. That's the source of truth and I believe what is trying to be solved for for most frameworks. In your example, where does name come from originally? Let's assume it's a contact app. If the user picks a different contact, what updates the name, etc...

If the user can display 2 contacts at once, etc...

The requirements are a bit too vague so i'm guessing here.

The design were talking about is mutating local state to update the view.

Unchanging variables (like a name from a db) are provided on construction and not relevant.

Selecting a new contract to 'open' creates a new contract element. No need to update the existing element.

----

If you're talking about "if I edit <input> here it updates <input> there as well", than I believe those are gimmicks that reduce usability.

If I understand your example correctly: a multi-contract view where the user updates a 'name' in both. IMO its a better UI to explicitly have the name:<input> _outside_ the contract elements. The contract element can do nameInput.onchange =(e) => {...} when constructed to update itself.