postcss-nesting plugin versus preset-env nesting for lean builds with CSS Nesting spec compliance

PostCSS core does not transform nesting. Nesting is provided by postcss-nesting or by the nesting feature inside postcss-preset-env, and the two approaches differ in pipeline weight and spec handling.

The goal is a deterministic nesting transform that follows the CSS Nesting Module without adding unnecessary feature transforms to the build. The constraint is build overhead and configuration stability: a dedicated plugin offers fine-grained options such as noIsPseudoSelector, while preset-env bundles nesting with other future CSS features and is stage-gated.

An unresolved decision is how starter kits and teams should choose between a minimal dedicated plugin and a single preset pipeline, and how to avoid inconsistent defaults when both mechanisms are present.

Which approach produces identical flat CSS output for the same nested source under current spec rules? Does preset-env nesting with an explicit stage pin provide the same :is() pseudo-class handling as postcss-nesting with its options? How should a config prevent duplicate nesting transformations when preset-env and postcss-nesting are both available in the dependency graph?