I don't have configurable delays in the latch / scan enable signals. They're just hard coded in the FSM

What I mean is that the FSM execution speed is "controll-able", as you have it. I think it is important - as you have it in your case - that the rising edge and falling edge of the latch_enable signal happen at different events relative to the scan clock rising edge, so that there are no "race conditions".

Ah yeah right. But given the delay we will most likely encounter what I'm doing is adding explicit wait state so that we can have a faster "shift" part and then only slow down for the critical parts ( latch / select / .. ).

Nice!