My browser / operating system: ChromeOS 14541.0.0, Chrome 144.0.0.0, No Flash version detected
Blocks like “Next costume” then “wait 0.05 sec” change speed depending on their order in “Forever” loops.
I demonstrate it here, if you need to see: https://scratch.mit.edu/projects/1280471791/

While it not may seem like it, it's actually running even when you press another key.

This happens because the end of the repeat block waits for 1/30 seconds, except that if no graphical update happened then it doesn't wait.
RokCoder described this much more detailed in https://rokcoder.com/tips/inner-workings.html

In the case of your project:

forever
wait (0.05) secs
next costume // changes graphics but doesn't wait for the screen to update
[↓ so the loop waits instead]::#ffffff
end

forever
next costume
wait (0.05) secs // waits enough for the screen to update so the loop doesn't have to
end

If both loops are running, then even if they are in sync, the costumes aren't because one of the sprites waits almost until the other switches costume. While the loops are in sync they run at the same speed because the “next costume” block of the first script causes both scripts' loops to wait. But the loops can also actually get out of sync because wait blocks don't wait the exact same number of ticks when there is lag or something, and in this case the second script can actually become faster again

So, I'm going to summarize this as "it's not a bug but more of a Scratch Programming Pitfall because of the way Scratch includes an animation delay as needed and also allows you to specify very small amounts of wait time that are inaccurate because of this sometimes imposed animation delay".

Thanks y'all! Appreciate the explanation, now I can apply this to my (future) animations!, though I do have a question- would that make the version with “next costume” first be technically more accurate, timing-wise?