postcss-preset-env versus individual plugins: balancing build speed and transformation duplication

Goal: decide whether to rely on postcss-preset-env as a single‑plugin solution or to compose the same transformations with individual plugins (e.g., postcss-custom-properties, autoprefixer, postcss-nesting) in order to eliminate duplicate transformations while still targeting the last two browser versions.

Constraint: the build must preserve correct source‑map output, but PostCSS’s handling of map options becomes ambiguous when both inline: true and annotation: true (or inline: false) are supplied, leading to inconsistent map generation across versions. It is unclear whether overriding preset‑env’s internal plugin list or explicitly disabling overlapping plugins resolves the duplication issue without breaking the source‑map behavior.

Questions: Does using postcss-preset-env with a custom plugin list that excludes overlapping transformations produce fewer duplicate rules than chaining the individual plugins? How does PostCSS combine the map: { inline: true, annotation: true } and map: { inline: false, annotation: true } settings when both are present in the configuration? Which approach yields more predictable source‑map output across PostCSS 8.x releases?