This makes me extremely nervous. The reason we intercept the setter is because there is no implementation of before/after values that you could reference in value changed. Historically  the setter checks to make sure the value has actually changed before it actually does anything which prevents needless churn and endless callback loops like I recently fixed on the item site widget. This makes me particularly nervous because you might even get this to pass all the tests, but encounter debilitating performance hits in real use. 

If you've accounted for this problem already somehow that's fine. I just saw this comment and alarm bells started ringing. It's hard for me to actually read a huge commit like this on an iPad.