22.1.3.24 Array.prototype.sort (comparefn)
There are still some missing exceptions to trigger "implementation defined" behaviour (but see also bug 3089 why the term "implementation defined" is considered to be too broad).
(1) consistent comparison function
> Calling comparefn(a,b) does not modify obj.
This exception needs to be changed to "Does neither modify obj nor any object in obj's prototype chain".
Reason:
The initial list of exceptions when implementation defined behaviour is acceptable (before "Otherwise, the following steps are taken") checks for indexed properties on obj's prototype chain ("The result of HasProperty(proto, ToString(j )) is true"). But this check is only performed once in the beginning. So it's still necessary to handle the case needs when comparefn invalidates this assumption.
(2) Side-effects when invoking ToString in SortCompare
The two ToString calls in steps 18 and 20 may modify obj or an object in obj' prototype chain. If that happens, implementation defined behaviour needs to be accepted.
(3) Dynamic results for ToString in SortCompare
The two ToString calls in step 18 and 20 are currently not required to produce consistent results. This makes the built-in lexicographical order less restrictive compared to when an explicit comparator function is supplied.
(4) Sort on proxy objects
For the same reason that currently accessor or non-writable/non-configurable properties trigger implementation defined behaviour, applying Array.prototype.sort on a proxy object (or if a proxy object is present in the prototype chain) should allow implementation defined behaviour.
fixed in rev27 editor's draft
fixed in rev27 draft