Right now, bounded feels ok to me.  If the queue fills up, we block the event-handling thread until the command-engine has a chance to catch up.  

Also, the "command queue" is something we may expose as an controllable API so you can see what's waiting to be run and alter it.  So I know there will be work there.  For now, having such a small buffer lets me catch ridiculous scenarios early.  I also think more than, say 10, task requests in the queue *IS* too large.  Blocking the event thread (and therefore ACK-ing clients) is a pretty good back-pressure scenario.  We should see less requests come in as we work off our queue, limping along.  IF I get an OOM because I have an unbouneded queue, we're completely dead.  I'd rather have the backpressure be a natural back-off that's just inherent in how you use the server than a sudden explosion.

You're correct in the three scenarios.  2 is what will happen when play run blocks.  We need to do some more thinking in this area. For now the bounded queue isn't the end of the world, as I expect us to have to fix this before the prototype is released so we have the "Pending Task" API.