Is this closed now? There are substantially more assertions in the system now.
I don't think that having a changeThreadState() method would be helpful for native threads. There are very few places where execStatus gets changed. Adding a changeThreadState() method would just be superfluous noise. On the other hand, I'd be happy to see more (correct!) uses of assertAcceptableStates() and friends. But, unlike green threads where state transitions were mostly synchronous except for when the thread was in JNI, the state transitions in native threads are much more asynchronous - hence there are fewer things that can be correctly asserted. This is not a bug, but a direct outcome of native threads being more correct.
Green threads were broken. The FSM approach was especially broken - it didn't allow things that Java programs should be able to do, like suspend a parked thread. Are you suggesting that fixing those bugs constitutes a regression and that we should reintroduce those bugs into the current code because it would somehow help documentation?
The current state transitions are clearly documented. See the javadoc for RVMThread.
JSR-166 worked almost on the first try in native threads; the only bug had nothing to do thread state transitions. I was unclear about the need to release the java.lang.Thread lock, and so that led to some deadlocks. That's now fixed, and JSR-166 works. So JSR-166 is not a good example for arguing in favor of the old approach. Also - take a look at the implementation of park() and unpark(). They're simpler now, in large part because we're not using a FSM to implement them.