core-js global namespace pollution in multi-library environments

When utilizing core-js in its global mode, the library modifies the ECMAScript prototype chain to provide missing features. This behavior is standard for application-level development, but it introduces risks in complex environments where multiple dependencies might rely on different versions of the same polyfill.

The primary concern involves the internal detection logic used by core-js to determine if a feature is natively supported or already polyfilled. If a dependency requires a specific version of a proposal-stage polyfill while the application provides a different version, the global namespace may be overwritten multiple times, leading to inconsistent runtime behavior across the bundle.

How does core-js resolve version conflicts when a global polyfill is already present but differs from the required implementation?
Are there configuration options to prevent global prototype pollution while still utilizing the useBuiltIns Babel integration?