Just make sure you don't ever use incremental compiling to build production jars. There are some edge conditions that exist in both scala and java that cause wrong behaviour to occur. It has to do with information lost when the compile occurs. A full clean and compile produces correct results.
I have 2 scala programs in production, one of which also has one java file (merssenetwister inlined) and I deploy incrementally built jars without any problems so far.
Here's one example, in order, w/incremental compiling enabled in Java:
Class A contains public static final String x = "x"
Class B contains public static final String y = A.x
Class A modified, A.x = B.y
Result: A.x and B.y = "x"
clean and compile, no code changes
Result: A.x and B.y = null
The reason this occurs is because information is lost during compile. The compiler optimizes the references away and doesn't fix them w/incremental an compile. This occurs in both sbt referencing javac and the eclipse incremental compiler in Eclipse IDE.
While this is contrived, the main point is that more complex interactions occur where these references may not be updated properly and you may end up with behavior you were not expecting due to these optimizations. Interestingly, I think the problem can be solved if the compiler were to keep incremental metadata explicitly stating where these dependencies exist. This certainly is the case with eclipse, where the IDE knows about the link, but still produces behavior that is dependent on compile order and not on the code change itself.
Interesting, I never had this happening to me, and I have not tested your example, but I'm bookmarking this to try some time later. Can you confirm this is a problem with sbt 0.13?
Use "sbt ~compile" or "sbt ~test". IntelliJ 12 + Scala plugin even an external running sbt incremental compiler to do compilation for the IDE.