Stale module cache results when re-@using a Sass file in the same entry point

In Dart Sass, the @use rule loads and executes a module only once per compilation unit, caching the result for all subsequent references. This produces a stale cache condition when the same entry point needs to observe updated variable values or mixin definitions from that module without splitting the build into separate compilation runs.

The @forward rule does not bypass this behavior; it proxies the underlying module, which remains subject to the same single-load logic. The uncertainty is whether any documented compiler option, API setting, or import hook can invalidate that cache or force a separate evaluation cycle within a single pass.

Is there a supported mechanism to force module re-evaluation within one Dart Sass compilation? Does the JavaScript API expose cache-control behavior distinct from the CLI? Are there configuration flags that alter single-load semantics for @use?