Ohne die Diskussion zu kennen, würde ich sagen, dass @if ohnehin nicht das Optimum ist. if ist eine binäre Entscheidung, man benötigt also zur Abbildung nicht-binärer Konditionen weitere Hilfmittel (in Form von Operatoren wie AND, OR, NOT und/oder binäre Entscheidungsbäume. Warum also nicht gleich die "parallelen" Konstrukte verwenden, bei denen beliebig viele nebeneinander gleichberechtigt vorkommende Möglichkeiten erlaubt sind?

Und falls @when nicht einfach als Ersatz für @if gedacht ist (also parallel und nicht bloß binär), dann hielte ich das für begrüßenswert. Wenn man Programmtexte mit if-Entscheidungsbäumen ausformuliert, die eigentlich parallele Strukturen darstellen, sieht das schon rein optisch verdächtig aus.

Die Wahl des "when" ist eigentlich kein schlechter Vorschlag. In SQL beispielsweise werden genau damit auch die in anderen Sprachen verwendeten switch/case-Konstrukte deklariert:

CASE ausdruck
WHEN ausdruck1 THEN ergebnis1
WHEN ausdruck2 THEN ergebnis2
ELSE default_ergebnis
END

Das aber ist das, was die Spezifikation vorschlägt (wobei CASE und END aufgrund der Klammerung entbehrlich sind und die defaults optinal bleiben können). Ein @when ersetzt also streng genommen nicht @if, sondern ist bereits ein Ersatz für switch/case, die ihrerseits eine Erweiterung von if sind.

Problematischer sehe ich da eher die Entscheidung, Programmlogik in CSS einzubauen. Aber wenn (was aus praktischer Sicht sehr begüßenswert ist!) das kommt, dann gerne gleich in dieser erweiterten Form.

SASS (und somit auch die älteren Codes) würde das zu nichts zwingen. Allerdings letztlich in gewisser Weise überflüssig machen, wenn man die Entscheidungen über den Transport des CSS dann auf den Client überträgt und nicht beim Server belässt.