Well, that is definitely complex but it doesn't seem to need to rely on process order.
It seems to me that you could setup the objects with Listener FSM's that get orders from a Manager.
For instance if the player changes his state then it simply updates thisState manager which broadcasts a signal across all FSM's to do something, you could make it a unique FSM like changedPolarity and somewhere in the object FSM structure have a listener state waiting for that event, when it is triggered then the object changes. This will control your system fine, and you won't need to worry about process order because those objects are constantly waiting for an update to be handed to them by the Manager.
You can repeat this for each mechanic as necessary.
You can also have the manager enter a Negative state and have every other object just reading to see what state the Manager is in, if the state name is "Negative" then the object does xEvent to respond to that, this would be put in a listener state so it is listening for something to be done and send an event based on that, just get into another listener state to wait for further changes.
To illustrate it think of a light switch, the switch can do one action - up or down - and that action affects everything wired up to it - lights, phones, computers, whatever. Those items are waiting for a command and the switch triggers it. You can do the same with a Manager and put listener states on the objects that can be affected by that switch/manager.
If you need more events, more managers, whatever then just stack them up and create new FSM's if you're worried about simultaneous changes. That is the whole advantage of using FSMs and States.