Well C5:30 is just being used for debug. I don't want my code to rely on it.
Got it; I missed that the B3:1/1 rising edge increments the step counter, C5:0, on rung 0.
This is working now, and you are only looking to "clean" things up?
I don't see the need for unlatching the MSG .ENs on Rung 0000; the counter changing value will unlatch those later on each MSG's instruction rung, when each [EQU C5:0.ACC N] goes false.
There might be some advantage to reversing the order of the MSG instruction rungs, so each MSG needs to wait for the next program scan, because you are relying on rising edges.
I don't see the need for the EQUs on each branch of Rung 0002; you are only catching rising edges anyway. [Update: I think I see it now].
It might be possible to somehow combine Rungs 0000 and 0002; a CTU triggers on a rising edge, so sending bits through an OSR, and then feeding that OSR's output (B3:1/1) to counter seems redundant.
I am of two minds on using a counter to keep track of steps in a sequence: if the logic between steps is simple, then it seems cleaner use that logic; if the logic gets too busy then it is worth using a counter or INT. I think this is a case of the former, especially because the transition logic is identical between steps: each MSG instruction is triggered by the .EN OR .ER of the previous MSG's control, can be sealed in by its own .EN, and reset by ORed XIOs on its own .DN and .ER; I think that latter bit only works if the MSG rungs are in reverse order. I'm not sure that will be cleaner though - running an OR of all .ENs and .ERs into one counter, and then having only the EQUs of that counter driving the MSGs, like you have now, might look cleaner.