Description
It is considered a semver-major to add a new top-level module. As a result, it is very difficult and time-consuming to land new experimental features that should have their own namespace. What I propose is that we introduce a top-level module which would function as a "nursery" of sorts for experimental APIs, allowing them to be landed in minor releases with the intent that they get their top-level module later--reserving the name in npm before landing would remain required though.
The name of the module is less important than the function to me--could be "nursery" or "experimental" or anything really. The point is to have a separate namespace set from module names at the time a new namespaced feature is introduced, allowing the feature to be introduced without being attached to something not entirely related (as happened with AsyncLocalStorage, it's relation to async_hooks is an implementation detail) and giving it a more clear indication that this thing you are trying to use is experimental.
This would mean that something like require('experimental').my_feature would eventually be promoted to require('my_feature').
There could additionally be something like require(name, { experimental: true }) which functions the same as require(name) but also will attempt to return require('experimental')[name] before moving on to checking node_modules for matches. The specific shape of that API is not so important as the concept.
The overall idea is to provide a way to accelerate being able to land experimental features while also providing a more clear indication that the feature could in fact be changed completely or removed at any time. That possibility of change or removal is a statement we already make, but is kind of a lie in practice as, for the most part, once we land something in core we're stuck with it if the community starts to adopt it. We have many "experimental" features that people used anyway, but if we had a more strictly defined sandbox where churn was actually encouraged, I feel we would have less cases of users expecting something to remain unchanged when they shouldn't.