The most significant issue IMO is that the standard library doesn’t not take its own semantic requirements seriously. If the standard library itself is willing to make exceptions to its own semantic requirements (IEEE comparisons where total order is required) then it sets the precedent that it is ok to wave hands a bit. Is this really what we want? It would create a minefield for generic code if the Swift community does not take semantic requirements seriously.
The places where the lazy collection API violate performance requirements also make a somewhat uncomfortable. However, in that case the worst that happens is bad performance, not a correctness issue. The tradeoff made here is understandable and much less likely to cause significant problems in practice.
Semantic compromises on something as fundamental as reflexivity of equality and total ordering for comparisons just seem like a really, really bad thing to me. If this isn’t a showstopper for a language intended to support correct generic programming, I don’t know what could be.
I haven’t heard any arguments justifying the current state aside from source compatibility. If we want Swift to be a great language, I think we should be willing to eventually, someday take on the source breakage required to fix this. It will be painful, but the alternative is worse IMO.
Semantic requirements should mean something and should not be violated, especially not in the standard library itself.