@use module adoption boundary when replacing Sass @import in Dart Sass

In Dart Sass versions that support the module system, the @import rule is deprecated in favor of @use and @forward. Legacy projects built on LibSass or Ruby Sass cannot adopt @use because the module system is exclusive to Dart Sass. The @use rule provides namespacing and private members, and modules are executed only once across the dependency graph, whereas @import can duplicate content and pollute the global scope.

The unresolved question is whether a stylesheet can safely combine @import and @use during a gradual migration. Documentation warns that mixing the two can lead to unpredictable compilation order and duplication, but the exact boundary of that risk is unclear. It is also uncertain how third-party libraries that still rely on @import should be integrated into a @use-based codebase without forcing an immediate rewrite.

What is the precise compatibility boundary when replacing @import with @use in Dart Sass? Is partial migration within a single file structurally safe, or does the execution model require a complete conversion? How should unconverted dependencies be handled in a project that has adopted the module system?