> What's the history behind this fork and what is it likely to mean in terms of fragmentation? In particular what are the irreconcilable beliefs on each side that have led to this?

What I've managed to put together, corrections welcome:

Typesafe has been moving to stabilize Scala, primarily to make it more attractive to enterprise clients. Prior to 2.10, even point releases broke binary compatibility; now compatibility is maintained for those and they're making efforts to make minor releases binary compatible. The tooling they've produced and the testing framework that builds all the major libraries in the ecosystem and checks for binary compatibility means they now have quite possibly the best binary compatibility regime of any language.

Typesafe recently published a roadmap for the next few releases, saying that the next release would focus exclusively on Java 8 support and remain compatible with the current release. This means work to merge any new features won't even start until January 2016, and those features are unlikely to be in an official release until 2017.

Less frequent and more compatible releases are what a lot of people have been asking for, and it would be very awkward to maintain Java 8 and pre-Java 8 releases of Scala. So the typesafe position that there can be no new features in the release that introduces Java 8 (so that people will definitely be able to switch to Java 8 without making any code changes) makes a certain amount of sense. At the same time it's meant Scala's getting "frozen" in a bit of a weird state; macros were a recently-introduced experimental feature and the official version is kind of half-finished (there's a branch with a more complete version). And there are a couple of features that are quite small and simple but would be a tremendous help for the kind of code the typelevel guys work on (e.g. partial application of types would be a very simple syntactic rewrite, and there's already an implementation as a compiler plugin), and there's long been a feeling that they were coming as soon as we figured out the little details - so to then be told that we won't see these features until 2017 at the earliest was a bit upsetting.

So there was a bit of consternation among the typelevel folks - a group who maintain some quite abstract and powerful libraries that tend to push the type system a bit further than most user code. Some of them started seriously talking about porting their libraries to one of the smaller, more experimental languages with a more elegant type system (Idris, Ermine, or I forget the other option). At the same time, the Scala community now has a lot of expertise in maintaining binary compatibility across quite complex changes, so at some point Miles came up with this idea. I don't think a fork would have happened otherwise - most of the goals can be achieved by compiler plugins (at the cost of being harder to maintain), and if they were going to break compatibility they might as well have jumped all the way to another language. But if the typelevel guys can pull off this "conservative fork", where they'll use their own compiler to compile their libraries but those libraries will then be binary compatible with "vanilla" scala and usable by ordinary scala users, then they get the best of both worlds. It's ambitious, but I hope it works out.

> I haven't tried Scala yet, but my gut reaction is I should stick with Clojure until the dust settles. A fragmented community around a relatively niche language is never good.

If they're maintaining binary compatibility then that should keep fragmentation to a minimum. Honestly I don't think this changes much compared to how it was with compiler plugins - if you're building some super-duper-typey project with these advanced features then maybe you'll muck around and use this forked compiler, but if you're a normal user then you can ignore it and carry on using their libraries without noticing any different.

Plus even if the Scala community were to split in two, I think either half would be bigger than the Clojure community.