As clearly shown in the log in ticket #2699 the barrier coordinator reports confusing things when the test fails on one node and it continues with next step and enters next barrier.

[JVM-Node3] - illustrate how to startup cluster *** FAILED ***
[JVM-Node3]   java.lang.AssertionError: assertion failed: timeout (9853256595 nanoseconds) while expecting 3 messages
[JVM-Node3]   ...
[JVM-Node1] [ERROR] [11/12/2012 05:15:48.711] [StatsSampleJapiSpec-akka.actor.default-dispatcher-5] [akka://StatsSampleJapiSpec/user/controller/barriers] RoleName(thrid) tried to enter 'done-2' while we were waiting for 'all-up' (akka.remote.testconductor.BarrierCoordinator$WrongBarrier)
[JVM-Node3] - show usage of the statsService from one node *** FAILED ***
[JVM-Node3]   java.lang.RuntimeException: barrier failed: done-2
[JVM-Node3]   ...
[JVM-Node2] - illustrate how to startup cluster *** FAILED ***
[JVM-Node2]   java.lang.RuntimeException: barrier failed: all-up
[JVM-Node2]   ...
[JVM-Node1] - illustrate how to startup cluster *** FAILED ***
[JVM-Node1]   java.lang.RuntimeException: barrier failed: all-up

This is not a critical problem, since you learn that the reason is the first failure, but I guess it can be a bit confusing for new users.
In the cluster tests we have eliminated this problem with the withFixture in MultiNodeClusterSpec.
// Cluster tests are written so that if previous step (test method) failed
// it will most likely not be possible to run next step. This ensures
// fail fast of steps after the first failure.
I don't know if that can be done generically in MultiNodeSpec (test fw agnostic)