The nodeRequestScopedFeaturesStoreFactory features store is based on an top-level scoped variable in a module, attempting to achieve singleton lifecycle (and thus the same store returned, wherever it is called) by virtue of the "module cache".

Since NextJS applications (and no-doubt other frameworks) are executed using multiple workers, executed in parallel during runtime, the concept of a single module cache does not apply. See issue:

The pattern of using a singleton during build or render to have a global view of the state of the server is just something that we are currently not optimizing for.

When opting for a custom server, this also "does not run through the Next.js Compiler or bundling process".

This means that an attempt to prime a features store in one entrypoint (which may be the only one that has context relevant to prime these) will not cater for all, and the store will be found empty in other entrypoints.

The nodeRequestScopedFeaturesStoreFactory relies on singleton values held in top-level scope, which . This may be mitigated via use of a cross-realm Symbol (see here) in a future update, as works with express-http-context