The only thing I can think of offhand: time the execution of Symbol.for. Mostly, this won't be terribly illuminating, because the bulk of the work (hashing input + looking in table) will be the same in both cases, and won't take long. But, assuming the registry is a hash table, what you could do in one script is pollute the registry with enough strings to trigger several hash table rebuilds (which you can detect by outsize results from Symbol.for - you add enough strings to provide a good representative set of timings).

Then another script could detect this by doing the same operation and seeing if no call to Symbol.for took much longer than any other. This gets you 1 bit of information... is that useful?

(Also, I wonder what they do about symbol table exhaustion.)

As for the results, they don't themselves hold any extra information, I don't think. Regarding Symbol.for: if the table contained the requested symbol already, it will return that symbol. If it didn't, a new symbol will be added, and returned. These are the only two options, and the caller has no way of knowing which was taken.

And regarding Symbol.keyFor: if the input was previously returned by Symbol.for, returns true. And if not, returns false. Neither tells you anything because the caller can only have acquired the symbol by doing one of these two operations itself, meaning it isn't getting any information that it didn't in theory have already.

Think of `Symbol.for("foo")` as if it were the string "foo". The string "foo" is also global, when passed across iframe boundaries it still retains its meaning. One can use this string on either side. Using it doesn't observably instantiate some global flag, though internally there may be interning and whatnot. Similarly, using Symbol.for("foo") doesn't instantiate any flag, observably.