It’s not dependent on the block update order, but when researching my old code for this code I almost thought it was. Now having looked at the code again, I finally realized it is dependent on block update order and the method I used to prevent it is basically useless.
Currently, when it updates a rod, the method that gets the moderation value isReactorRodModerated() tells the rod to update to the moderation value oModeration to be equal to mModeration, mModeration being the value that is set by other functions, and outputs the new oModeration, while setting mModeration back to false. When a rod has been tagged for moderation, i.e. mModeration set to true, it can obviously still be called on the same tick and directly update that to oModeration, which gets directly output. This is obviously only possible, if the rod gets called after being tagged for moderation in that tick and not if it does after ticking itself, meaning that the system is dependent on block update order. It’s basically no different from just setting oModeration and directly outputting that.
The solution to this would simply splitting the isReactorRodModerated() into two methods, isReactorRodModerated() and updateReactorRodModeration(), (and of course isModerated() and updateModeration() on the rods) one which just returns oModeration and one which updates oModeration to have the value of mModeration, but is only called in the second subtick, so after all rods have interacted and set mModeration on the rods.
Not sure if @Gregorius wants to quickly fix this small thing himself or if I should do another pull request soon.