core-js 3 feature-path migration: side-by-side version serving during zero-downtime rollout

Migrating a small application from core-js 2 to core-js 3 without downtime crosses a documented module boundary: core-js/fn/... specifiers become core-js/features/..., and aggregate entry points such as core-js/stable become available. In Babel, the configuration transition moves @babel/preset-env from corejs: 2 to corejs: 3 under useBuiltIns. The unresolved decision is whether core-js 2 and core-js 3 can be served simultaneously during a staged rollout. core-js does not document a supported side-by-side compatibility mode, and its polyfills are not always pure: they may install getters, setters, or replace built-in methods. Loading a second major version could overwrite the first version's patched built-ins with different observable semantics, creating duplicate global patching conflicts.

Because core-js-compat targets can drift from real browser usage over time, is there a documented approach to run both majors concurrently during a transition window, or must every entry point switch at once? If concurrent serving is not supported, what is the safest way to stage the cutover without risking prototype replacement conflicts? Are there specific core-js 3 entry points that are safer than others when a legacy bundle might still be cached or active?