Migrating a shared component library from core-js 2 to 3: global build or core-js-pure?

Context

We are upgrading a component library (consumed by several internal apps) from core-js 2 to core-js 3. The major version change reorganized the import paths — our existing core-js/fn/array/from style specifiers no longer resolve, and the documented replacements are prefixed entry points such as /es/, /stable/, /features/, and /stage/.

The unresolved decision

core-js 3 ships two flavors: the default global build, which patches built-in prototypes, and core-js-pure, which exposes the same polyfills without touching the global namespace. The documentation positions pure mode for library authors, but switching to it means every polyfilled method becomes an explicit import, and some of our consuming apps already load the global build themselves. We are unsure whether mixing the two in one dependency graph is safe, and which entry-point prefix (/es/ vs /stable/) is the right baseline for a library that should not polyfill unfinished proposals.

Questions

• For a library consumed by apps that may independently load the global core-js build, is core-js-pure the documented recommendation, and what breaks if both flavors end up in the same bundle?
• Which entry-point prefix is the intended stable baseline for published packages — /es/ or /stable/?
• Does Babel's useBuiltIns: 'usage' with corejs: 3 interact correctly with a dependency that imports core-js-pure directly?