Perhaps that may be a solution: create a thread with your series of operations, have it block itself waiting for a signal from the UI with the users answer before proceeding to the next step.
It’s getting late, so that has a strong likelihood of being a load of bollocks 
Good luck.
I’d just do a class that will incapsulate the context and state with a few public methods for restarting the wizard and state change plus and callback in plugin UI part. There is no any CPU heavy stuff in there, so an old state-machine in a modern way will be work just Ok triggered from the UI events…
BTW, I always thought that JUCE plugin UI runs in it’s own thread and all OS messages are just passed to it (with some kind of non locking fifo or something), thus I thought that blocking the UI thread is kinda “local plugin issue”.