I just took the time to read the proposal and glance through the discussion, and I thought I'd pitch an alternative that I didn't see anyone else propose (maybe because it's a dumb idea 
). I think we should deprecate Sequence.elementsEqual(_:) and not rename it at all. As others have said in this thread, this sort of operation is relatively infrequent and its use is generally a code smell in "beginner" code, as the examples cited above show. However, we then need to deal with this:
elementsEqual(_:)is a generic method onSequence, we can use it to compare an instance ofUnsafeBufferPointer<Int>to an instance of[Int]. This is a potentially useful and non-redundant feature which would be eliminated if the method is removed altogether.
I think the solution here is not to provide a one-shot method that does this; rather, a possible solution I thought up of is to provide functionality so that this operation can be achieved in a relatively short composition.
Intuitively, I'd lump elementsEqual(_:) as a zip(_:_:) derivative, since it's doing something similar. Unfortunately, zip, as it is currently available, has some annoyances that make it unsuitable as a replacement. In particular, it silently drops the suffix of the longer Sequence, which makes it impossible to distinguish from say ([1, 2], [1, 2]) and ([1, 2, 3], [1, 2]). However, I think we could add a new method that does some sort of padding and returns a sequence out of that. If we create a method like this, say paddedZip(_:_:), now elementsEqual(_:) is relatively simple to write: we could just write it as paddedZip(sequence1, sequence 2).first(where: { $0 != $1 }) == nil. If we add mismatch to the standard library, this would be even more concise.
Overall, my thoughts were to make this entire class of operations easier to do, rather than trying to "baby-proof" a special-case operation.This is just a rough sketch a possible solution I came up with; of course, things like naming or semantics are free to change based on your feedback.