Just one word of caution on this. What you have here is a closed loop system. Inputs come in from the Sonoff devices, the flow decides what to do and outputs commands to the Sonoffs, this in turn causes more inputs at the front, which again may cause further outputs, and so on. It is possible that there may be some combination of inputs at just the right times (clicking multiple switches at almost the same time for example) that would cause the system to enter an unstable state with messages running round the loop and the lights switching on and off rapidly. I don't even know if it is possible to calculate whether your system may have any such unstable states.
It would be possible to remove such possibilities if you could determine whether a state change input was as a result of an output sent by your system or whether it was caused by an external event (someone pressing a switch). I don't know whether it is possible to know that or not. If you could tell then the system should be told to ignore inputs that come from commands generated by the flow. This would break the loop and it would not be possible to have an unstable situation.
In practice what you have will very likely be fine but if once in a blue moon when more than one switch gets pressed at almost the same time then it enters such a mode you will know why. Quite possibly in that event clicking the switches again will kick it out of that mode, or possibly not 
It would be worth trying to see if you can make it go unstable by clicking buttons randomly just so you know how likely it is.
that's what I was occasionally experiencing with my first flow.
I hope that this new sophisticated one will not suffer from this behaviour.
Previous issue was kind of reproducable when wifi went off and one of the switches was turned ON while others remained OFF, after wifi regain it started rapid switching.
It's not very common and I tried to simulate it with these new flows and looks like it's working properly.
I was thinking to add some kind of delay into the reading, but then it can cause issue when network will be bit laggy or so and switches would be unsynced. Not really sure how to solve this, maybe some kind of internal delay+gatherer of the states and then continue to the function after 1s or so, what do you think?
update: I found out JOIN to be breaking factor in current flow, as join basically waits 2 or 3 messages till it passes to Function node, which in real world means to press 2 or 3 different switches to actually invoke their sync.
So i've thrown away join node, and inside function node I no longer cares about which topic is the trigger as I (and tasmota) can live with double cmnd to trigger node, eg. tasmota ignores that command if switch is already in requested state.
Now it does look like working reliable.
What is now on the table are some corner cases in case wifi/reboot etc.
You can tell the join node to only wait for 1 message and to send outputs on all subsequent messages so it should have been possible to make it work.
yes, but then it's node which is not really needed as basically you are only passing what you have already, nothing really joining
Not if you are combining them into an object with multiple keys
which in this usecase is not needed as I'm sending cmnd to each topic anyway, so only needed thing here is payload ON/OFF
