Editorial: Explicitly define ambiguous namespace properties as undefined

[guybedford]

This ensures that the spec is explicit about ambiguous bindings on module namespaces that have not otherwise been imported in a way that would throw an error will always be undefined on the namespace, effectively skipping the unnecessary call to _targetEnv_.getBindingValue.

See issue #2399 for the exact details and scenario to which this applies.

[ljharb]

would it be worth exploring the web compatibility of making this throw?

[guybedford]

It's difficult to say, but it likely is a web compat issue at this point I'd guess. It could still be worth discussing further though. Another concern about throwing would be even just logging a namespace to the console would be enough to cause the error.

[anba]

There seems to be some kind of misunderstanding around ambiguous exports:

1. The string "*ambiguous*" is used nowhere within the spec.
2. The spec does use the string "ambiguous" (so without the asterisk).
3. "ambiguous" is a possible return value in ResolveExport, but in that position it's never used as a [[BindingName]] value in a ResolvedBinding record.
   • ResolveExport has three different return values:
     1. A ResolvedBinding record.
     2. null
     3. and "ambiguous".
4. Module namespace objects return undefined for ambiguous exports due to steps 4-5:

4. Let exports be O.[[Exports]].
5. If P is not an element of exports, return undefined.

5. The [[Exports]] slot of module namespace exports is set in ModuleNamespaceCreate. This list doesn't contain any ambiguous exports by definition, cf. GetModuleNamespace where the exports list is created.

[guybedford]

@anba thanks for the very clear explanation here, you are entirely correct! Yes, I missed that these were being filtered off the namespace by the string value "ambiguous" not being a ResolveBinding record.