We just have to make sure we don't require to have data which isn't present. For example Intl.NumberFormat accepts any currency and if the currency isn't known, it simply defaults to outputting the currency code:

js> print(new Intl.NumberFormat("en", {style: "currency", currency: "ZZZ"}).format(1))
ZZZ 1.00

whereas Intl.DisplayNames is required to detect and handle unknown currencies. (This example only works with JSC and SM, because V8 doesn't yet support the fallback option for the "currency" type.)

js> print(new Intl.DisplayNames("en", {type: "currency", fallback: "none"}).of("ZZZ")) 
undefined

And some currencies are even only supported for certain locales:

js> print(new Intl.DisplayNames("en", {type: "currency", fallback: "none"}).of("UYW")) 
Uruguayan Nominal Wage Index Unit
js> print(new Intl.DisplayNames("de", {type: "currency", fallback: "none"}).of("UYW")) 
undefined

any suggestion of how to phrase that in the spec text?

Maybe using a host hook as the source of truth for viable values for both enumeration and also other relevant APIs, and requiring the host hook always return the same values across calls?

Any suggestion of how to add such mandate into the spec text?

A normative note that says so, like https://tc39.es/ecma262/#sec-hostimportmoduledynamically has ("it must always do so for subsequent calls.").

We can work on the editorial language here after it is merged into ECMA-402.

For example, Intl.DateTimeFormat should support the calendar systems returned by Intl.supportedValuesOf("calendar"), no more, no less.

For time zones, what you describe is not the current behavior. Intl.supportedValuesOf("timeZone") returns only canonical time zone IDs (aka "primary time zone identifiers" in current ECMA-262 terminology), while Intl.DateTimeFormat accepts both primary and non-primary IDs.

FWIW, I think that this is the right default behavior, because AFAICT the main use case for Intl.supportedValuesOf("timeZone") is to power a UI dropdown of available time zones, and it would be bad UI to have multiple entries of the same time zone in the dropdown.

For calendars, a similar argument could be made for the deprecated islamicc calendar, where it's probably not good to have a UI dropdown of calendars with two essentially duplicate calendars.

We could extend Intl.supportedValuesOf to an options parameter e.g. Intl.supportedValuesOf('timeZone', { includeDeprecated: true }) if the caller really wanted to get the full list. FWIW, I'd heartily support doing this because it would let apps cache the full list of valid IDs to avoid having to create an (expensive) Intl.DateTimeFormat instance in order to determine whether an ID is valid or not.

requiring the host hook always return the same values across calls?

FWIW, similar language is already part of https://tc39.es/proposal-temporal/#sup-availablenamedtimezoneidentifiers and https://tc39.es/proposal-temporal/#sup-availablenamedtimezoneidentifiers.