If a resource can be held for multiple cycles in the schedule model, then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be take back out if the two instructions hazard. To fix this, make sure that we update the Available queue even on the first MOp of a cycle, pushing available instructions back into the ready queue if they now conflict.
This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. I'm not sure about the test changes here, but this improves scheduling decisions on our in-order cpu's.
This one I do know about. The A53 schedule holds the load pipelines for 3 resource cycles, so now decides to push one of the loads down later to not hazard with the other loads. This is similar to the aes_load_store case below I believe.