useBuiltIns: 'entry' vs 'usage' — covering third-party dependencies without shipping dead polyfills

Goal

Choose a useBuiltIns mode for @babel/preset-env that satisfies third-party dependencies' standard-library requirements while avoiding polyfills the application never executes.

Constraints and uncertainty

With useBuiltIns: 'entry', a single import (core-js/stable) is rewritten into per-feature imports filtered by browserslist targets. This guarantees coverage for any dependency that runs in the same global scope, but it also pulls in every polyfill the target matrix requires — even features only used by a nested node_modules package.

With useBuiltIns: 'usage', Babel injects imports only for the standard-library features it statically detects in transformed files. This eliminates dead polyfills from the application's own code, but it systematically misses:

• Features required by untranspiled dependencies (the default exclude: /node_modules/ behavior)
• Features accessed dynamically or reflectively (Object.keys polyfill needed only via Reflect.ownKeys)
• Polyfills needed by code loaded at runtime that Babel never sees

The corejs: 3 option must match the installed major version; a mismatch produces warnings and incomplete or duplicated polyfills. Teams also face a secondary decision on proposals: true versus stable-only, which affects API stability but not the fundamental coverage trade-off.

Questions

1. For a project with a mixed dependency graph (some ES2015+ packages in node_modules, some legacy), which mode produces fewer production incidents: over-inclusion from 'entry' or under-coverage from 'usage'?
2. If choosing 'usage', what is the minimal include/exclude configuration that reliably captures transitive dependency needs without re-transpiling all of node_modules?