It’s not just @-rules, but also other things like functions, where they’ve introduced their own that end up definitely incompatible with CSS and it’s just no end of pain as you try using now-ordinary CSS features and discover that a technical decision made fifteen or more years ago prevents you from doing so. (The deprecated LibSass is significantly CSS-incompatible; Dart Sass, I’m not sure: even a year ago it was still significantly incompatible, but they have definitely landed some important fixes since then so that it’s possible that their long-standing claim on https://sass-lang.com/ that “Sass is completely compatible with all versions of CSS” is no longer a blatant lie.)
I think most of the trouble is actually that Sass accepted the theoretical compatibility breaks on behalf of their users, who didn’t realise they were signing up for this, and end up discouraged when breakages happen and they have to resort to ever weirder and wackier workarounds that should work but somehow break things in some other part of their toolchain, et cetera ad desperationem.
I think it would have been much better if every piece of Sass syntax had used been clearly denoted by the use of the $ symbol ($@ instead of @ for its at-rules, a $ prefix on its functions, &c.), except probably for nesting (though not bare mathematical expressions, I’d force them to be wrapped in $(…)—they’re the worst to find when trying to port away from Sass syntactically rather than compilationally). $ was and is not used by CSS and could probably be agreeably reserved for such tools, and even if not, the unquestionable superiority for tooling (that it makes identifying Sass rather than CSS parts of the stylesheet textually trivial rather than absolutely requiring a compiler that is unlikely to be designed for general tooling use) would even make switching from $ to something else (e.g. a -sass- prefix, which would also be a reasonable choice, though slightly more verbose) genuinely easy.
But of course, that ship has long sailed, and I have no time machine.
I think most of the trouble is actually that Sass accepted the theoretical compatibility breaks on behalf of their users, who didn’t realise they were signing up for this, and end up discouraged when breakages happen and they have to resort to ever weirder and wackier workarounds that should work but somehow break things in some other part of their toolchain, et cetera ad desperationem.
I think it would have been much better if every piece of Sass syntax had used been clearly denoted by the use of the $ symbol ($@ instead of @ for its at-rules, a $ prefix on its functions, &c.), except probably for nesting (though not bare mathematical expressions, I’d force them to be wrapped in $(…)—they’re the worst to find when trying to port away from Sass syntactically rather than compilationally). $ was and is not used by CSS and could probably be agreeably reserved for such tools, and even if not, the unquestionable superiority for tooling (that it makes identifying Sass rather than CSS parts of the stylesheet textually trivial rather than absolutely requiring a compiler that is unlikely to be designed for general tooling use) would even make switching from $ to something else (e.g. a -sass- prefix, which would also be a reasonable choice, though slightly more verbose) genuinely easy.
But of course, that ship has long sailed, and I have no time machine.