The complication here is that there three kinds of equality that we might be talking about:
-
Whether two sequences are regarded as equal, regardless of actual differences in their elements. The simplest concrete example I can think of is a type conforming to
Sequencewhere all values or instances are==to each other, regardless of what their elements are. -
Whether two sequences are regarded as equal, because they consist of the same elements in the same order. Concretely, this covers all cases where
==and (the current)elementsEqualare the same. -
Whether two sequences consist of the same elements in the same order, regardless of whether the sequences are regarded as equal.
#1 is an equality test on sequences, #3 is an equality test on elements, and #2 is both simultaneously.
The objection to sequentiallyEquals is that (grammatically) it tends to suggest an equality relationship between sequences. That puts it into category #1 or #2, when in fact it's intended for category #3.
Another way of saying this is that a satisfactory method name really needs the word "elements" in it somewhere, and really needs "equal" rather than "equals".
That perhaps brings us to elementsSequentiallyEqual, which isn't a bad name, but it's not significantly shorter than elementsEqualInSequenceOrder (which is my current preference for the method name). That is not very different from elementsEqualInIterationOrder, but I believe this may be mis-interpreted as imposing an iteration order that's somehow different from the sequence order, even though they're really the same thing.
Please note that none of the above is about Set or Dictionary, just about Sequence in the abstract.
Also, after @adamkemp's recent comments, I'm wondering if the correct thing to do is to simply delete the elementsEqual API from Sequence. The use cases depend so much on the semantics of the conforming type, the convenience method may be more inconvenient than useful.