Duplicate core-js major versions in dependency tree cause conflicting built-in polyfills

The goal is to select a core-js import strategy for a reusable library that polyfills ECMAScript features without mutating global built-ins or conflicting with other dependencies.

Importing bare core-js mutates Array.prototype, Promise, and other globals, which can mask missing native support and collide with other polyfills. core-js-pure avoids global mutation but changes import patterns and may affect bundle tree-shaking. Subpath imports such as core-js/stable and core-js/proposals separate finished ECMAScript features from stage-specific proposals.

Assume core-js v3 is installed; v2 is end-of-life and v4 has no firm release date. Duplicate major versions may coexist in a dependency tree.

Which import entry point should a library use to avoid global mutation while preserving tree-shaking? Should proposals be imported separately from stable features? What mechanism can an application use to detect and resolve duplicate core-js v2 and v3 installations?