What I meant was that it's possible to emulate a custom key comparison predicate.

You just have to have a function that returns value for each input that behaves the way you want under strict equality comparison.

Implementing an `equals` function that returns a boolean is more convenient, sure.

Serializing (for plain objects with only JSON-serializable values that would be JSON.stringify) to strings or other primitives would of course be possible with object keys, too. But that's probably what you want for "record"-like objects, right?

And if you want better performance or compare non-primitive values, you'd have to do something more complex, that's what I meant by the lookup table.

But I imagine if you deep-compare large Record objects a lot, the performance wouldn't be any better, because the engine still has to do a deep comparison.

If I am not mistaken, Records/Tuples are in fact strictly limited to this case:

https://github.com/tc39/proposal-record-tuple#jsonstringify

So basically there is no difference to having a function serialize() that just stringifies your plain object, maybe with a caching layer in between (WeakMap?)

OK, thinking about it, the proposal really would help to avoid footgun code where performance optimizations are lacking, and too many deep comparisons or too many serializations are performed.