> I guess I > don't fully understand the issue, so I don't have an alternate proposal,
To help those reading this anew (but if responding, please also read the whole thread), the issue is: 1. You have a sorted collection 2. You change any of the properties of the Sort or SortField (the order, numeric or not, the field by which to sort, the sorting function, anything) 3. You (or, more frequently, the SDK itself, through a component's dataProvider) call getItemIndex() or removeItem() or removeAll() on that collection. In this situation there will very likely be a fatal. Reason: refresh() wasn't called on the collection, so it (as the code is designed now) assumes that the collection has been sorted by the *modified* sorting rules, when in reality it's sorted by the original rules. There were 5 potential solutions suggested in the thread, and for the moment I chose the first one (making Sort and SortField immutable, but with an intermediary stage of hiding the state setters behind mx_internal for a few "transition" releases), thinking that the benefits of moving errors from the runtime to compile time is greater than strict backwards compatibility. (For the code changes this would imply, see FLEX-34880[1].) If, however, we decide that strict backwards compatibility is more important, I can revert the current changes (which achieved this for SortField; Sort was pending) and change course (but probably not for this impending release). If indeed it turns out this change is undesired, I can also go back and review the other solutions in more depth. For the record, I still personally think that sometimes it's ok to (minimally) break backwards compatibility (eventually, after a few transition releases) in favour of a better designed, less runtime-error prone framework which encourages better coding. What's good is that people upgrading their projects would get compile errors rather than changed behaviour at runtime, which is much harder to detect. And if we document these changes well, it should make it relatively easy to transition. [1] https://issues.apache.org/jira/browse/FLEX-34880
