We maintain a custom implementation of the Map type which has a different API and semantics than the Map  defined by the ECMAScript standard (which we delete at runtime in the test runner). Historically, we didn't want to break user scripts in the wild which might depend on this type, but that's no longer a strong motivation now that we ship mongosh.

We do still depend on this implementation in our  cycle_detection library, which wants to store types like NumberLong as retrievable map keys. The following code snippet does not work with the standard Map type, because key existence uses referential equality

> map = new ESMap();
{ }
> num = new NumberLong(5);
NumberLong(5)
> map.set(num, "test");
{ }
> map.forEach((v, k) => print(`${k} = ${v}`));
NumberLong(5) = test
> num2 = new NumberLong(5);
NumberLong(5)
> map.has(num2)
false 

As we begin to evaluate using third-party javascript modules in the test runner, we might find that our non-standard Map causes unexpected behavior if those modules are using the type. In fact, this already might be an issue today because the vendored "fast_check" library is unwittingly using the custom type.

One option here is that we can rename the custom implementation to something more semantically correct for its existing use cases.