Looks appealing, but it is very confusing. At least with Sass/less etc you can easily distinguish between native css and non-native css constructs such as mixins and extends. But the additions rucksack make are ambiguous. Is it real spec, future spec or something that rucksack developers have added for convenience?
I'd prefer nextCSS with all the spec being based on what is actually going to make in into CSS. Otherwise it's the same downsides as preprocessing languages with the added bonus of not being able to easily tell what lines are native to css or not.
The API is intentionally transparent. The idea is that you're still writing in the CSS language (even if with non-spec features), rather than a DSL. So if you ever did want to rip Rucksack out and go back to-spec, you'd just run it and grab the output. Your overall structure, logic, and code would look pretty much the same, just with the (expanded) additions of the individual features Rucksack added. This often isn't the case when you're writing in a preprocessor, especially on a big project the input often ends up looking very little like the output.
And to clarify, yep Rucksack certainly isn't to-spec (present or future). It's a collection of handy features and shortcuts, like the compass/nib/bourbon of PostCSS. As timdorr points out, you could absolutely use it with cssnext (we do exactly that over at Simpla), you'd probably just want to disable autoprefixing, since cssnext does that for you.
I do like the features. I was drawn by the appeal of cssnext as a way out of needing preprocessing, by being able to use soon-to-be-supported css features straight away.
But adding new spec that looks like the CSS language is not transparent, it's ambiguous. It's not a knock perse. And like you say it does not lock you in, as you can rely on the output. But I wouldn't want to use it for projects that are distributed to other users, because now they have the burden of learning and distinguishing between constructs coming from rucksack and normal css spec.
Yeah we're thinking of enabling users to pass through option blocks to the individual plugins (like how precss and cssnext does things), the problem is that not all features match 1:1 with plugins. Legacy Fallbacks, for instance, is a sub-collection of 5 plugins, and passing a nested object to each of these would be awkward. Also most of the plugins used (and all of the ones I built for it) are pretty straightforward and don't take any options.
But feel free to chuck an issue up on github, this behaviour probably needs to be accounted for sooner or later.
I'd prefer nextCSS with all the spec being based on what is actually going to make in into CSS. Otherwise it's the same downsides as preprocessing languages with the added bonus of not being able to easily tell what lines are native to css or not.