Agreed this would be great but I would be curious to see how Bourbon would deal with their extensive and growing LibSass user base which has the feature set of Sass 3.1.

Just use the link to the CSS file in development an have your build tools concatenate everything for production. Certainly not a show stopper.

I wouldn't call random, non-hyphenated word breaks like that "looking very good"!

I am not a designer, and the only place I use sass is a bunch of static blogs, including my primary one. The command I run to compile my sass files is as follows:

  find . -name '*.sass' | onchange -s make css

where onchange is a simple command I've written that watches filesystem for events on files from stdin and runs command when they occur, and make css is simply

  sass --update _sass:dynamic/styles

So long as sass is in the $PATH, I'm good to go. I don't care how my sass files are translated to css files, I only care whether they get translated or not. In the last place I worked, they used guard for compiling less (sth. like sass) files and concatenating them, which was a frightening program with a huge configuration file, written in JSON. For concatenation, I'd do

  find dynamic/styles -name '*.css' | onchange -s cat dynamic/styles/*.css > dynamic/all.css

See, when your abstractions are processes, everything is easy. It's like git, one simply does not need to know if git commit is a shell script or a C program. It is a process, you need to call it, and that's it.

edit: put in absent redirection into the last command line.