Global polyfills vs. pure imports when bundle size and version isolation conflict

Context

A mid-sized application targets browsers from the last two years but must also run in a legacy embedded webview that lacks Array.prototype.at, Promise.allSettled, and several Symbol properties. The build uses core-js@3 with core-js/compat driven by a browserslist config, which currently emits global polyfills for the missing features.

Constraint

The team wants to reduce the production bundle by at least 15 KB (gzipped) and allow a newer micro-frontend to depend on a different core-js version without forcing a full repo upgrade. Global mode prevents version isolation because all consumers share the same augmented built-ins; pure mode enables tree-shaking and per-package versioning but requires rewriting every call site to use explicit imports such as import { at } from 'core-js-pure/array/virtual/at'.

Unresolved decision

Switching entirely to pure imports would satisfy both constraints but touches hundreds of files and breaks any third-party library that expects globals to be patched. Keeping global polyfills preserves zero-change adoption but locks the entire build to a single core-js version and leaves the bundle-size target unmet.

Which strategy minimizes total migration risk while meeting the bundle-size and version-isolation goals? Can a hybrid approach—global polyfills for the legacy webview entry and pure imports for the modern micro-frontend—avoid duplicate polyfill logic? What criteria should decide which features stay global versus which move to pure imports?