accumulate potential non-determinisms in our platform's JS

[warner]

first item: for of over an object being mutated might return a different order when the JIT takes over from the interpreter, so e.g. V8 might behave different depending upon local performance measurements that will vary from one machine to another

Another is the exact text of Error objects, or what happens when two errors are triggered by the same operation (which one gets thrown).

We want to enumerate whatever "wiggle room" the spec allows, and what it might take to observe it, and how we deal with it. We might deal with it by using only one specific version of one specific engine, or having lint rules that exclude the sort of code or operations that could provoke it, or by defining our language subset narrowly enough to exclude them.

[warner]

As investigated in #1872 (comment) , the JS spec is intentionally silent on the strong-reference relationship between Promises, the resolver/rejector functions you get when building one, any potential resolution value you've passed to them, and any potential callback functions you've attached with .then or .catch or .finally. My analysis of Node.js (documented in that ticket) shows slightly stronger relationships that are strictly necessary. Other engines might drop objects that Node.js would retain.

Without access to WeakRef, I don't think a Vat could observe these differences, but we should verify that claim. We should also thoroughly understand the specific behavior of any engine we consider, to make sure it will interact well with the liveslots code that does apply WeakRefs to promises and/or their callbacks (for the purpose of GC).