I've been thinking a lot recently about how SwiftUI has unconstrained generic parameters, and then adds more behavior using conditional extensions and was applying that here. But, you're right. Your point about implementing Equatable conformances is right on the money. While I feel like I'd want to change the sort order of a SortedSet more than I'd want to change the equatability check of Set, it would be inconsistent of me to argue that it's ok for Set to require Hashable, but not ok for SortedSet to require Comparable.
I definitely agree we ought to also have a more dynamic sorted set type, where the sort order wasn't baked into the type system. It wouldn't be trivial to design it -- I think we'd want to express the sort order using some composable & serializable construct like NSSortDescriptor. Foundation's new SortComparator type is one step towards this direction.
Another complication is that iirc SwiftUI requires RandomAccessCollection conformance, which B-trees cannot provide. B-trees are plenty fast at accessing nearby items once we already have an index -- and that seems like it should be enough to render things on screen. However, how do we capture the notion of a collection type that is "locally random-access" like that?
To me we need a new generic protocol as in IndexedSequence (for example), which would basically have the same Collection public interface but just requiring subscript access to be O(n) or O(log n).
This will also translate in having RandomAccessIndexedSequence, MutableIndexedSequence and BidirectionalIndexedSequence counterparts.
