Actually, as I think about it again, my analysis was incorrect. I don’t think this is really a bug.
ParGroup assumes that there are no node-ordering dependencies among its children – that is, all of its children should be able to evaluate in any order without breaking signal flow.
If there are any node-ordering dependencies (e.g., source --> effect) within a ParGroup, then it’s impossible to distribute the children among different DSP threads (thus CPU cores).
Therefore, the ordering of children within a ParGroup is arbitrary. It doesn’t matter if y or z is at the tail. (If it does matter, then ‘x’ should be a regular Group – in which case, supernova does respect
I changed the github issue to documentation. The help should be clear that users should not expect to control node ordering within ParGroup.