Remove sort from intersection

details.md

@@ -64,6 +64,6 @@ All of these methods take only a single argument. Some of them, like `union`, co
 
 ## Order
 
-For each of the `Set`-producing methods, in the resulting `Set`s all elements which were in the receiver appear first, in the order in which they appeared in the receiver, followed by elements which were only in the argument, in the order in which they appeared in the argument.
+For each of the `Set`-producing methods with the exception of `intersection`, in the resulting `Set`s all elements which were in the receiver appear first, in the order in which they appeared in the receiver, followed by elements which were only in the argument, in the order in which they appeared in the argument.
 
-That this is possible for `intersection` in time proportional only to the size of the result (and not the receiver) is not obvious, but in <a href="https://matrixlogs.bakkot.com/TC39_Delegates/2022-07-11#L0-L54">this discussion</a> it was determined that it ought to be.
+It was determined that this order is not efficiently achievable for `intersection` in all implementations, so for that method only, the order is instead the order of the elements within the smaller of the two sets. This means that the order of the resulting set depends on the relative sizes of the two sets, which is a sharp edge, but the committee thought it was the best of the available options.

spec/index.html

@@ -66,15 +66,10 @@ <h1>Set.prototype.intersection ( _other_ )</h1>
           1. Let _inThis_ be SetDataHas(_O_.[[SetData]], _nextValue_).
           1. If _alreadyInResult_ is *false* and _inThis_ is *true*, then
             1. Append _nextValue_ to _resultSetData_.
-      1. NOTE: It is possible for _resultSetData_ not to be a subset of _O_.[[SetData]] at this point because arbitrary code may have been executed by the iterator, including code which modifies _O_.[[SetData]].
-      1. [id="step-intersection-order"] Sort the elements of _resultSetData_ so that all elements which are also in _O_.[[SetData]] are ordered as they are in _O_.[[SetData]], and any additional elements are moved to the end of the list in the same order as they were before sorting _resultSetData_.
     1. Let _result_ be OrdinaryObjectCreate(%Set.prototype%, « [[SetData]] »).
     1. Set _result_.[[SetData]] to _resultSetData_.
     1. Return _result_.
   </emu-alg>
-  <emu-note>
-    It is expected that implementations can achieve the order required by step <emu-xref href="#step-intersection-order"></emu-xref> in time proportional only to the size of the output, not _O_. For example, using <a href="https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables">this data structure</a>, the relative order of two elements within _O_.[[SetData]] can be determined without needing to iterate the entire `dataTable` array by directly comparing the pointers to their entries in `dataTable`.
-  </emu-note>
 </emu-clause>
 
 <emu-clause id="sec-set.prototype.difference">