this has a lot to do with the way we handle requests... It seems like they should be going into some kind of queue... or
something...
The first call to deploy determines that there are two tasks that have to happen... the server needs to start and then
the deploy needs to fire if that is successful. The first call triggers the start-up... The second call to deploy
should detect that the server is starting... and wait for that startup to complete before attempting to start the
deployment...

Ah yes, now I see why it doesn't work. Solving the "what to do if the server is in "starting" problem was deliberately
out of scope for the 6.1 plugin and was supposed to be part of reworking the way that thread operates, which as you
know, wasn't completed for 6.5.
I expected that such a use case would be rare, and the work around should be start the server separately, then do both
deploys.