or are there any plans to extend it, to model the more useful local transitions from the 2.0 spec?
There weren't any plans until I read your post :-). It seems that any local transition can always be converted to an external transition or an in-state reaction. The only benefit I see is improved performance (one state exit & entry less) under IME rare circumstances. So, the question is: How often do you use such transitions?
Unfortunately I have no practical experience of using state charts yet, (I have done a lot of research/reading/designing), so can't answer your question. I want to use simple HSMs to control the threads in a GUI application (a more complex version of the Dining Philosophers Problem essentially). In my designs I very often use a composite state as the source for a transition, simply to avoid repetition (- avoid lots of transition lines from each sub-state on my diagrams). However the behavior I want is exactly the same as if I'd sourced the transition explicitly from each sub state. That is, I explicitly don't want the entry and exit actions of the composite to be called. That is perhaps why UML added local transitions - not for performance reasons, but for behavioral flexibility and expressivity. If you only model external transitions and want to use entry/exit actions you've essentially lost much the power of HSM's to represent FSM's more efficiently. This is I think a killer argument.
Tests with deep history produce a static assertion if you attempt to transition to history of a containing state. UML 2.0 explicitly permits this.
I disallowed such transitions because they don't seem to make sense and there was no indication that they are allowed under UML 1.5. IIUC, such a transition would simply leave & reenter the current state, right? If so, what good is history for when the same effect can be achieved by simply giving the state a normal transition to itself?
Giving a state a normal transition to itself would invoke it's entry/exit actions, or if modeled as an internal transition (in-state reaction) do none. Transitioning to deep history (of a containing state) should (in my opinion) invoke the entry/exit actions all the way back up to (but not including) the state containing the history. So as you can see I was interested in notationally efficient ways to invoke chains of entry/exit actions back up the hierarchy. The other thing to note is that this sort of transition to history technically doesn't require any extra storage of the deep history since it is just the current state (the composite state might not need to be parameterised with has_deep_history).
Thanks for the feedback!
Hope that all makes sense. If I do use HSMs for my app, I think I'll use boost/statechart, and for now avoid entry/exit actions. Having reviewed several implementations, every time I think about writing my own HS library I realise how many options there are. Also you've already done all the queuing and locking for me. Yours, Tim Milward