Player-set delays in many if not all devices, from levers/plates to bridges to traps. A fixed 100 step delay is "unrealistic" and extremely inconvenient, a huge restriction on what we can currently do with the mechanics.
I'm a little unsure about player-configurable delays. If a delay is required, it should be enabled through building. Now, 100-step multiples (give or take other delaying factors) are already possible, but consider 'solving' the (other than the fixed delay) "instantaneous action at a distance" issue.
How about a 'speed of action' delay between lever/plate and its switched mechanism? (With or without further token delays intrinsic to the mechanics themselves.) Proportional to either Root(dX^2+dY^2+dZ^2) or Max(dX,dY,dZ), depending on in which manner you want the universe to propagate its messages[1]. And for a precise delay you could place your lever exactly so far away from your mechanism-enabled-whatever, or 'delay loop' (out and back, or polygonally, allowing for the water-logic/whatever delays on the inter-stage transfer), or even just take advantage of the delay to get a "mexican wave" effect of bridges/doors/floodgates, all connected to a single repeater off to one side and 'chomping' sequentially.
(Imagine a row of 1-wide bridges acting off a repeater guarding the fortress. At any one time, there's always at least one path into the fortress (perhaps even wagon-width), but those who try to route through it have to catch the step just right, and may end up being catapulted if they step on a section too late to get off the other side before it raises. Also imagine the game lag that might accompany this innovation, whether from the almost continual re-pathing or the implementation of the dynamic landscape changes themselves.
[1] Though naturally it would be just "wait until you should know about this before acting on it" background-delays, not be
actually wave-fronts of propogated messages or beamed information pathing to destinations... Unless you wanted it to be more realistic and relate to where the ropes or push-rods must be laid in order to enact a physical connection, in which case the delay could be worked out on a one-time best-route pathing basis (which may be far less optimal than the best-route pathing possibility at the time of activation). But that's making things complicated.