ok, I am revisiting this topic.
I want to do what rlk suggested, namely enable the locks to go back up when the switch is triggered again.
This will restore the "contract", as Elviz put it, of what a switch means functionally speaking so that the subsequent switch triggers will at least have a corresponding action from the gates.
I just looked at all the replays in the table to see if any would become obsolete. None of them involve re-entering the switch halos so there's no problem there.
In the meantime, anyone care to chime in with any objections before I commit the change?
In addition, maybe we could carry this conversation forward a little and try to resolve the quandary before a future release.
I would like to see:
1) A switch that signals on or off STATE ("moving" and "not moving") with its respective green and red halos. (this is what we have already)
2) An additional key that can designate a switch which initiates a one-time action (ie. has a timer) but signals instead the "on" or "off" POSITION of it's target. For example, the gates on locks.map could be red=closed, green=open. This would also mean that you would have to leave the halo and re-enter to trigger the change in position, it would function the same as a switch with no timer. (ie. hard level sync.map)
(side note: I never really felt a strong need for the ability to "disable" a switch, especially since we basically use blockers for that anyway, which I like. The red halo is an enticement to unblock and activate the switch. But I do understand that some other level designers may want to make use of one which becomes disabled after being triggered, which would be weird to use a blocker for)