Dart Sass and LibSass in one codebase: can @use modules and slash division coexist safely?

Context

A shared style library is consumed by two build pipelines: one compiles with Dart Sass (the sass npm package), the other still runs a LibSass-based compiler. Core syntax like variables, nesting, and mixins is expected to match because both implementations historically followed the same sass-spec suite, but the module system and division behavior are known divergence points.

Constraints and uncertainty

The library currently uses @import everywhere, which Dart Sass flags as deprecated while LibSass never implemented @use at all. Migrating to @use is not purely mechanical: namespacing and load-once semantics can change cascade and variable-override behavior, and LibSass would fail to compile it outright. Slash division is a second concern, since Dart Sass restricts / as division and pushes math.div(), while LibSass keeps the older interpretation.

Assume current Dart Sass as of 2026 and the final LibSass release; exact warning text should be verified against the installed versions.

Questions

• Is there a documented subset of the language that stays portable across both implementations during a transition period?
• Does math.div() compile under LibSass, or must division be avoided entirely in shared files?
• What is the recommended way to confirm which implementation a build tool actually resolves before attributing output differences to the language?