Mixing core-js global polyfills and core-js-pure in one dependency graph: which mode should a shared library depend on

Integration boundary

A workspace contains an application plus several shared packages. The app and one package load the global core-js build (core-js 3), while another package imports from core-js-pure to avoid polluting globals. The goal is to decide which mode the shared library should declare as a dependency, given that both builds ship the same implementation but expose different APIs.

The uncertainty is the interoperability boundary: pure-mode code does not observe globals patched by the global build, so instanceof and prototype checks may behave differently across modules depending on which mode each component uses. Assume core-js 3 and Babel with useBuiltIns: 'usage' and a matching corejs: 3 option.

Questions

• If the global build patches Array.prototype in the app, will pure-mode array methods in the library reflect those patches, or does each mode operate on its own wrapped implementations?
• Does importing both core-js and core-js-pure in the same bundle risk subtle inconsistencies, and is there a documented way to align the two modes?
• For a published library, is core-js-pure the recommended choice to avoid polluting consumers' environments, and what duplication cost does that trade-off involve?