Many (a lot more than in basically any other computer program I’ve ever used) actions in Dorico are very heavy computationally, and since they are run on the same thread as the UI, you have to sit there waiting for them to complete before you can continue interacting with the program in any way. While in many cases it does make most sense to make the user wait for the UI to reflect its new state, as which actions are valid may have changed, there does seem to be a lot of interactions whose validity and effect remain well-defined during orthogonal resource-intensive state transitions and which therefore should remain available during that time.
For example, what prompted me to propose this is that sometimes I will accidentally click on the Engrave mode button when I mean to switch to Play mode instead. Switching to Engrave mode is very intensive (depending on the file, I’ve had it take nearly a minute), and during the long wait for it to load, nothing in the UI is interactable–the program is frozen until it’s done. So, if I meant to click on Play, I have to wait for it to do all the work to load Engrave mode, which I will then click away from once its done, rendering all that computation work pointless. I see no reason that I shouldn’t still be able to click the button for Play mode while it’s loading Engrave mode, since it is guaranteed to remain clickable in Engrave mode. Then, once I have clicked Play, it can cancel the loading task for Engrave mode and stop wasting processing power and time, especially since it will just dispose of the result anyway once I’ve successfully switched to Play mode, though even if it kept the result there’s still no reason not to generate it in the background.
I imagine this would require a substantial refactoring of how the UI is written but I think the work it would take to make actions independent of each other whenever possible would be worth it.