Regarding development burden, if ICS is implemented as additions to the language, then it can get all updates to the rest of CoffeeScript from "underneath" - the only proviso is that CoffeeScript syntax doesn't change incompatibly with it. And as ICS can be seen as a simple macro (plus libraries it uses), I would guess it is implemented this way (simple source transform on top of CoffeeScript, not hacking at the Jison grammar). This is one way around the issue you raise.

Regarding the whether it's part of the language or a library as a distribution issue, it depends on what benefits users. For syntax, there's some benefit in uniformity (other developers can read it). I'm seeing ICS as a suggestion of a new feature in CoffeeScript. If it's really good (meets a need; bugs and design mistakes are fixable and fixed; it doesn't break other things), it could be back-integrated into CoffeeScript proper. Whether to do so can be better decided once data exists. :-)

It's a great forking model for exploring new syntax, IMHO.

EDIT but it breaks the CoffeeScript philosophy of readable JavaScript, and (eg) addes debug line numbers in to the source code (see "load" on the sample code). Also, other examples and more details on ICS here https://github.com/maxtaco/coffee-script/blob/iced/iced.md