The LSG talked about this pitch, and we feel that it doesn't make a very good case for adding an abstract requirement to Equatable. The examples in the document are all pretty vague: they use the new requirement to avoid a supposed linear operation, but they leave that operation unspecified. Actual code with a concrete operation in it might provide a stronger motivation, but might also reveal that it's only really useful when applied to a concrete type.
Because the requirement is abstract and provided by arbitrary Equatable types, it struggles to define its expected semantics, which often only make sense in the context of a specific conforming type like Array or String. It also has to introduce optionality to the result type, which really feels like it ought to be reflected statically: if many types do not provide a meaningful implementation of this operation, perhaps it shouldn't be available on those types.
We would prefer to move forward with only the proposal that adds concrete isIdentical methods to the CoW types in the library. If experience with that proposal reveals that it is useful to have a generalization, we can reconsider this then. That is how generic proposals are best developed, by generalizing them from an existing pattern that's come to be well-understood. I've agreed to be review manager for these proposals, so I'll go read that proposal document and see if I have comments to make on the PR.
Also, I'm sad to say that the claims about == in the proposal are not true because of types like Float for which == is not universally reflexive.