Side-effect idempotency boundary for @use modules

The Sass @use directive loads each module once per compilation and namespaces its members, providing a reliable mechanism to avoid @import-style repeated global injection. However, when modules emit side-effectful CSS rules that reference shared dependencies, the once-loading guarantee does not inherently prevent duplicate selector emission across multiple entry points that independently @use the same partial. This creates a design decision point: whether such CSS should reside in modules at all, given that @use controls loading frequency but does not enforce semantic idempotency for arbitrary global rules.

Compilers like Dart Sass implement the module system according to the Dart Sass specification, while LibSass and node-sass are legacy lines with divergent deprecation timelines for @import and differing module resolution behavior. Teams evaluating module boundaries must therefore account for implementation-specific warnings, variable override rules (where non-!default overrides are compile errors), and the practical impact of shared partials on final CSS bundle size.

Can a module configuration enforce idempotent CSS emission for side-effectful rules without breaking namespace isolation? Does the !default variable override semantics reliably prevent duplicate variable-driven CSS across modules? How should CI pipelines version-pin Sass implementations to capture deprecation warnings and duplicate selector counts when migrating from @import to @use?