You have said: I'm trying to fix semantic bugs in the way various collection operations handle situations with mixed membership semantics
I believe this statement is misleading and is at the root of our apparently irreconcilable differences. Many if not most of the problematic examples of mixed membership semantics involve an argument declared to be a Set or a Collection. In the current framework, the Set and Collection interfaces prescribe a single membership semantics. As the specification of SortedSet clearly states: Note that the ordering maintained by a sorted set (whether or not an explicit comparator is provided) must be consistent with equals if the sorted set is to correctly implement the Set interface. It is not the responsibility of a specification to define the behavior of a method when it operates on an incorrectly implemented argument, and where there is no specification of behavior, there can be no semantic bug. I am not saying this to be pedantic or to disparage your concerns. The concerns are valid, but your statement suggests that they can be resolved by a series of bug fixes, which I believe would be a high risk strategy. The proper way to address these concerns is to consider them all to be part of a redesign of the framework, one in which Set and Collection explicitly define a range of possible membership semantics and specify the intended behavior of all methods in all combinations of membership semantics. (Do not take this as an endorsement of such a project. I consider it to have a high risk to value ratio, and if it were up to me, I would not fund it.) In the meantime, you might identify changes that make certain methods more forgiving when faced with non-conforming instances of Set or Collection. This is not inherently a bad thing, but as the change is not fixing a bug, the risk of behavior/performance regressions must be very low. Alan
