core-js global vs core-js-pure imports in a shared library: which entry mode to standardize on

A shared JavaScript library consumed by several applications needs to polyfill newer ECMAScript features, and the team must pick one core-js import strategy before publishing. The documented options behave differently: global entry points such as core-js/stable or per-feature paths like core-js/actual/array/group-by patch built-in prototypes and globals, while core-js-pure exports the same polyfills as standalone functions without mutating global scope.

The uncertainty is practical. Global mode risks conflicting with consumer code that feature-detects or redefines the same natives, and the actual namespace additionally pulls in stage-3 proposals whose semantics may still change. Pure mode avoids mutation, but if any dependency in the tree also loads global core-js, the bundle can carry both implementations with inconsistent behavior. Selection is also environment-sensitive, since core-js uses compat data shared with Babel's preset-env via browserslist targets, so the "right" import set depends on the consumers' target browsers, which the library does not control.

Assume core-js 3.x and a bundler-based build (webpack or Rollup).

1. Should a published library standardize on core-js-pure per-feature imports, or is there a supported case for shipping global polyfills from a library?
2. Is importing from actual acceptable for a library, given that stage-3 proposal behavior may change, or should only stable paths be used?
3. How can consumers detect that both global core-js and core-js-pure ended up in the same dependency tree?