In the middle of page 195 it is said that processing the given example in parallel would only work if we didn`t care about the order of the result.
I think that this is not true. The of-Method produces an ordered stream and the collect-Method should be deterministic, so process the elements in the encounter order, since nothing else is stated in the JavaDoc. This should also hold for parallel processing. In fact, the JavaDoc of the method explicitly says: "Like reduce(Object, BinaryOperator), collect operations can be parallelized without requiring additional synchronization."
I tested the example using a parallel stream and got "wolf" like with sequential processing.
I think if a method is deterministic or not shouldn't change from version to version. And for the collect-method I cannot find any hint in the Java-Docs that the method might not be deterministic for parallel processing, like there is for methods like findAny or forEach. In contrast the Java-Doc of the method says: "Like reduce(Object, BinaryOperator), collect operations can be parallelized without requiring additional synchronization". There's also a similar example given with StringBuilder. Also the documentation about mutable reductions at https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html#MutableReduction explicitly says: "We can use the same technique to parallelize mutable reduction as we do with ordinary reduction."
The wolf-example fulfills the common requirements for reduction operations stated in the Java-Docs (accumulator and combiner are an associative, non-interfering, stateless function and the supplier creates a new result container) - so there should be no problems with parallel processing.