Natively implemented platform APIs exhibit a set of behaviors which are presently unachievable in ES: they have object-associated private state which can be recognized and retrieved by multiple instances of the same API.
Date_fromRealmB.prototype.valueOf.call(new Date_fromRealmA);
// Does not throw; all Date.prototype.valueOf functions work with objects created by all Date functions
Both the private field proposal and hand-wired WeakMaps allow implementing ‘slots’ in ES. These are effectively equivalent to the slot concept used in the specification of internals. Strictly speaking, the cross-realm limitation that emerges with private fields and WeakMap is not a limitation of either, but rather a consequence of the fact that a module source text is associated with no persistent, common state that is reachable from ES code. Each time a module source text is evaluated, any ‘slot names’, regardless of how they are achieved, are uniquely created.
The agent has a means of determining if two specifiers resolve to the same module instance within a single realm, so there is already a concept of source text identity more sophisticated than ‘a particular sequence of bytes’. Hypothetically, an agent could share state between ‘instances of that module’ regardless of what realm they are evaluated in. The import.meta API could provide a hook for provisioning access to it. But what could be added there that would enable ES code to exhibit native cross-realm branding behavior?
Naively we could imagine an extensible null-prototype object, say import.meta.ohNo, reused for all module instances, acting as an open-ended bucket. Although this would work, it would never be acceptable since it would represent a side channel. If any approach were acceptable, it would need to be realized with a much narrower API.
I think such a narrow API might be possible, but it would depend on the existence of reified private names of some kind. Assuming these took the form of private symbols, we can imagine import.meta.privateSymbolFor, a function that behaves like Symbol.for. The difference would only need to be the scope of the registry: ‘all instances of this module’ rather than ‘all realms’.
This could also probably be realized as e.g. Symbol.for(import.meta, 'str'). The particulars of the API don’t matter.
I’m not really looking for feedback on this as a proposal (it’s not one). I doubt enough interest exists and there’s no such thing as a private symbol or equivalent presently — previous proposals for them have been rejected. My question is just: would such an API be sound, or would it still represent a side channel?