Establish requirements for bi-directional bindings

There are a number of ideas floating around on what a bi-directional binding should actually do. On the surface, it sounds simple: synchronize the values of two properties. The devil is in the details, though. Say we have a bi-directional binding between properties A and B.

1. What should happen if a change in A causes B to be updated, but the entity that controls B rejects the update and sets B to a different value right away? This is common with models only accepting values in a specific range, for example.
2. When should the synchronization happen? We commonly don't want to update the model for every key stroke in a text edit field. Rather, we want to wait until the user "commits" the value in some way. Before that happens, the values can be different.
3. Should an update to either property cause other, regular, bindings to break? From a language point of view it should, because now the value does not reflect the result of the binding anymore
4. Is there even a use case for having an extra binding on either A or B? The typical case this tries to solve is a model field being synchronized to an editable view field. If the model value is governed by a binding, then it is in fact not editable. If the view value is the result of a binding, then it's effectively write-only, and the model should not update it.