I came across what looks like a bug in the indexOf (and lastIndexOf) method of SortedList. The first line of code in both methods seems to be used to skip the optimized indexof search based on sorted data when that sort cannot be guaranteed (which makes perfect sense).
The bug, i believe, is that these methods both use source.indexOf(object), where i believe that the intent is to use super.indexOf(object). If i am understanding the goal of this code, it is simple to fall back on the slower linear search of the data in the current list, but by giving the index in the source (pre-mutated) list, an invalid value is returned.
Please let me know if you think this is incorrect, as i just applied the change to my codebase, and though it appears to function better (makes remove(object) remove the correct element), I'd hate to discover an esoteric case i'm missing.
Another related topic, is that the sorted index search while fast, breaks if the monitored objects have changed without notifying the sortedlist. It can be said that that violates the contract of SortedList, which is fair, though the default assumption of "STRICT_SORT_ORDER", has a high-requirement for the collected elements to be capable of change notification. For my code, i'm ok, as i have switched to AVOID_MOVING_ELEMENTS mode; as much to minimize user annoyance during edits, as to lessen notification requirements for processing integrity.