Makes good sense to do this. One can think of two "views" of state machines from a Commons SCXML perspective:
(a) A document-centric view: This is the n-ary tree represented by the SCXML document. The top-down relationships from document root are important
(b) A engine-centric view: This is an intricate graph with all the wires between transition targets and initials and histories drawn out on top of the n-ary tree in (a)
For version 0.5, the focus has been to take (a) and the wiring needed to transform it into (b) was done as a separate step. While this will continue to hold to some extent, the consistency and conveniences needed for procedural tweaking of the object model (such as setting symmetric references) are definitely desirable, though it might mean we lose the side-effect free setters in some cases. While it may not be obvious,
SCXML-23 has the beginnings of such an effort.
I am setting the fix version to 1.0 primarily because, on a strict prioritization basis, this lags behind other things I want to do. However, if anyone fancies a tested patch, there is no reason not to apply it immediately.