My intent was to perform most message passing by way of queues and use thread signaling for tasks that don't lend themselves to that approach. If the general concept (as contrasted with implementation) is flawed, I love to get set straight.

In the abstract, it doesn't make sense (to me, in isolation of your ultimate goals), to have a thread who's only purpose in life is to read from the keyboard and then queue that input to another thread to action. Especially when that other thread already has other things to do which, on the basis of what you've told me so far, have no inherent relationship to the input (command) actions.

You say that your "intent was to perform most message passing by way of queues" but the command input only becomes a "message", if you queue it. If you do not queue it, the input is simply input that needs to be actioned. And that can be done immediately by the reading thread as I've shown above.

One of the most basic principles of message passing architectures is that you do not poll. If you are going to poll, you are better off using an event loop architecture--though that is rarely a good idea. A message agent should just wait on its input queue until there is something for it to do, and then do it and go back to waiting. Your implementation above where the same agent is polling two queues completely defeats that basic principle.

But reading between the lines of your post, your ultimate goals seem to be very different from the code/descriptions that you've posted so far. In that respect, it is difficult, and probably pointless, to make further recommendations.

If you have a description of the goals and requirements of what you are hoping to achieve, then it might be possible to suggest an architecture that lends itself to development towards those goals, as a starting point.