Theoretically, I would say the correct order should be A and then B since in order to click on a button, it needs to have the focus. Only one dom element can have the focus, so first, the textbox loses focus. You can see this behavior if you have the focus on a textbox and then click-and-hold the button. The textbox immediately loses focus.
What happens in your setting when you do this? Does the OCh-textbox-microflow get triggered before you release the button?
One hypothesis for this behavior is that the triggering does happen in the correct order (first A then B), but your conclusion is incorrect and caused by A doing some activities that take less time locally compared to in the cloud. And B does less of that, so starts a fraction later compared to A, but reaches the point of your observation earlier.
My guestimation is that it is due to the delay from client to server communication.
Running on a local machine the tacky behavior of stepping out of focus of the input widget by clicking on the button and thus trigger the other microflow is less experienced then when communicating with the cloud server.
But I wonder; what is the reason of the On-change event in the first place.
Because when the user is able to change something in text box A and click directly on the button, it seems that there is no need to provide the user feedback on the entered value. And thus why run a On-change instead of executing the On-change behavior in microflow B