La incoherencia se debe a que la operación abstracta Number::toString no está bien especificada.

Su pregunta se reduce a BigInt(String(x)) ≟ BigInt(x) , que podría suponerse que es una igualdad para los números enteros x , pero de hecho no lo es.

En su caso particular, para x=18446744073709551616 o x=18446744073709552000 (o cualquier valor intermedio, e incluso un poco alrededor), la representación de cadena del número produce '18446744073709552000' mientras que el valor matemático exacto es 18446744073709551616. (Lo sabemos porque La operación NumberToBigInt es exacta: obtiene el valor matemático del número o un error si no es un número entero).

También encontramos la siguiente nota en Number.prototype.toFixed :

La salida de toFixed puede ser más precisa que toString para algunos valores porque toString solo imprime suficientes dígitos significativos para distinguir el número de los valores numéricos adyacentes. Por ejemplo,

(1000000000000000128).toString() devuelve "1000000000000000100" , mientras que
(1000000000000000128).toFixed(0) devuelve "1000000000000000128" .

Para responder a la pregunta titular

¿Por qué Number(“x”) == BigInt(“x”) … solo a veces?

Es debido a la precisión limitada de los valores numéricos de coma flotante. Hay múltiples literales numéricos que se analizan exactamente en el mismo número. Similar a su primer ejemplo, tomemos el bigint 20000000000000000n . Hay un número de punto flotante con el mismo valor matemático, específicamente

+1 × 0b10001110000110111100100110111111000001 × 2 ^0b10001
= 1 × 152587890625 × 2 ¹⁷
= 20000000000000000

Hay varios literales de números enteros que se evalúan en este valor numérico: 19999999999999998 , 19999999999999999 , 20000000000000000 , 20000000000000001 y 20000000000000002 . (Observe que no siempre se redondea hacia arriba). Esto también es lo que sucede cuando los toma como cadenas y usa unario + o Number en ellos.

Pero si toma los literales bigint respectivos con la misma representación textual, se evaluarán en 5 valores BigInt diferentes . Solo uno de los cuales comparará igual (con == ) a, es decir, tendrá el mismo valor matemático que el valor numérico.

Esto es coherente: siempre hay exactamente uno, y es el que se puede representar con precisión como un número de punto flotante.

¿Por qué este comportamiento no es consistente?

Su confusión proviene de la representación de cadena del valor numérico 18446744073709551616. Al imprimir el número literal 18446744073709551616 , o también +'18446744073709551616' , obtuvo 18446744073709552000 (porque la consola usa String() / .toString() internamente), lo que le hizo asumir internamente que 18446744073709552000 era su valor matemático, y que 18446744073709552000n debería ser igual a él. Pero no lo es :-/

 console.log(18446744073709551616..toString()); console.log(18446744073709551616..toFixed()); console.log(18446744073709552000..toString()); console.log(18446744073709552000..toFixed());

¿Cuál creer?

Supongo que esto se debe a que no se especifica la implementación exacta del valor matemático (o al menos no pude encontrarlo).

La comparación de igualdad abstracta se especifica https://262.ecma-international.org/11.0/#sec-abstract-equality-comparison

Si Type(x) es BigInt y Type(y) es Number, o si Type(x) es Number y Type(y) es BigInt, entonces

Si x o y son cualquiera de NaN, +∞ o -∞, devuelve falso.

Si el valor matemático de x es igual al valor matemático de y, devuelve verdadero; de lo contrario, devuelve falso.

Entonces, un BigInt debe tener un valor matemático de algún número entero, y un Número debe tener un valor matemático de algún tipo de número de notación científica, por lo que las comparaciones deben ser intuitivas, pero exactamente cómo su motor JS implementa el valor matemático no sigue la especificación en espíritu