Within an Infragistics 8.2 UltraComboEditor, we had the following properties set via C#:

        DataSource = dataSource;
        ValueMember = "Measure";
        DisplayMember = "Name";
        DataBindings.Add("Value", repository, "Measure");
        DataBindings["Value"].DataSourceUpdateMode = DataSourceUpdateMode.OnPropertyChanged;

where dataSource was an array of objects, each with a property Measure, and repository was an object with a property Measure. (Those strings are actually constructor parameters -- just using explicit strings to simplify the example.)

In the course of some refactoring, the name of the property on the objects in the array was changed to BaseEnum (the objects are actually wrapped enumerations, for the curious), but the name of ValueMember above was not changed. And yet, the combo box binding continued to work through initial testing, beta testing, and even after release... until two customers emailed in noting that the combo box was no longer changing the underlying parameter. We were able to dig out the problem by careful study of the source code repository... despite being in the awkward position of not being able to replicate the buggy behavior internally.

Two part question:

1. What's happening under the hood that allowed the binding to continue to function, and/or what might be unique about those two users that caused the binding to (correctly) fail? (O/S version isn't alone the answer, and we get the unexpectedly functioning binding on machines that have never had a version of the software before, so we're not looking at rogue binaries).
2. Are there tools that might have been able to warn us about the misbind, even if something was cleaning up behind?