Agreed. That's one area that's not being handled. The other is the attribute value being set to something that doesn't correspond to a UI value, such as the available options in a `<select>`. In either case, some sort of notification needs to be broadcast, though it starts to get tricky.

Because 1) validation failure is silent, 2) `on()` subs can call `e.preventDefault()`, and 3) both the `validator` and `setter` can reject the value, I would need to (re)publish the attribute change event to include a `preventedFn` and a replacement `defaultFn` that mimicked Attribute's `_defAttrChangeFn`, but triggered the same logic if `_setAttrVal` returned false.

That's pretty invasive, and it still doesn't close the loop when an `on()` subscriber changes `e.newVal`, which would also need to be tracked on the change event facade to signal that the UI (which may have originated the change) needs to be updated.

This all still doesn't answer the question of *what* should happen, only how to make it happen. Maybe an event is fired? Seems the easy answer, but is it the right one?