Up front, I am not certain about either of the effects of this change and this might be one for the bin…

I am uncertain that binders should restore the previous state when they are canceled. We have never done this before and it is a big change. Doing this would fix some strange behaviors of bindings though, like I mention, a "has" binding to "false" would react to key changes by deleting the property for each visited key. A "get" binding for a free key paints each entry with the bound value. By restoring the previous state for "get", "has", and "property" bindings, we eliminate some strange side-effects. One downside is that the binding will retain the previous value of a property until it’s canceled, which may or may not be a problem. Another downside is that it becomes more difficult to express the case when you intend to paint a property, if we ever actually intend to do that.

As for the "get" binding to null case, first, the behavior is distinct from a "property" binding. After this change, a property binding continues to ignore null. It is possible to create a binding to a mutable key, with `object[key]` or `object.property(key)` notation, but it is not a common case. However, property bindings would still exhibit the property painting behavior. We never use `delete` on an object. For one, it’s not observable. It also would destroy the property change listener. If we ever “delete” a property, we would merely set it to null, but FRB doesn’t support this before or after this PR. You point out it should not because we depend on the current behavior. I’m okay with that, but I should point out that, if we allowed binders to set properties to null, we could still disable a binding like `enabled ? property : null <- value`.

This change does make "get" and "property" inconsistent regarding how they handle a null value. That makes me uneasy.

However, what we win for this change is that "get" bindings do not need to be accompanied by "has/defined" bindings in common cases.

Before:

```
element.style.get("color") <- color;
element.style.has("color") <- color.defined();
```

After:

```
element.style.get("color") <- color;
```

And we can also do the parent/children thing:

```
parent.children.has(this) <- true
```

This would cause an object to remove itself from its parent when this binding is canceled.

Suffice it to say, this is new territory and we should proceed with caution.