This is dead on, however I say it's a client code implementation detail that the object the view is bound to is the same one other parts of the app are bound to. Two way bindings about marshalling data out of the dom into JS land, and unfortunately developers seem to pick the wrong JS land object to store the view data in: the model. The model is best viewed as the client's best understanding of what is on the server: the canonical state of the modeled object in the world. Changing the value of inputs doesn't change the state of the object in the world until you press the save button. You do still want a canonical place for view bindings to bind to, so that different views of the same object are guaranteed to stay in sync (think the slug in an index as well as the detail view in a show action), and I say its not worth sacrificing this guarantee because we can't structure our code around binding to non-canonical representations. This suggests the edit views should be bound to something which knows how to apply itself to the model, so that upon saving, the canonical place can remain as such and updates with the new data.

In Batman we really want to make this other object a reality and have been scheming about "draft" versions of models for quite a while, but still haven't quite nailed down how to do it when things like associated objects enter into the mix.