This was also brought up at the last CG meeting, to specify a general builtins: ['js'] compilation option to turn on all JS builtin features.

This would provide an ergonomic shorthand avoiding having to enable every single JS builtin individually. With the wasm:js/... prefixing model this would be a well-defined concept enabling all stable builtins under the wasm:js/... name.

In addition, in the ESM Integration JS API (both source phase and instance phase imports), it would be able to provide this thus enabling the default set of builtins available, without needing a dedicated ESM Integration JS API change for every new builtin added.

This also touches on some of the backwards compatibility concerns raised in #1584 (comment) where the concern is that builtins fall through to the user-provided imports when not available in the host. So that turning on a new builtin subsystem under say builtins: ['js'] could formally be considered a breaking change.

I think it might not be such an issue, but we should also not assume, either.