My (limited) understanding of state machines requires that the next state logic be well defined. The QSM seems to create a hybrid state machine where the next state logic is an array. So, each state has an input which is the queue and then outputs it as next state logic. Luckily, I don't think this will change whether or not it is a Mealy or Moore machine. However, the utility of a next state array comes with the cost of increased complexity. I'm not sure you can use the traditional state machine representations as the queue allows any state to transition to any other state. And, as you mentioned, states can exist with no next state logic. This notion is completely against traditional SM design. If you have large SM's and/or want to regulate the transitions, I would be weary of using the QSM. If you have to use a QSM, I would try and model it as close to a traditional SM as possible. Hopefully you can eliminate any major vulnerabilities in your code.
As for the Mealy/Moore question, one good place to look for information is in university course notes. Here is a >10 year archive for some good holiday reading. I'm sure there are better places for this, but this this one is familiar to me. http://www-inst.eecs...0/archives.html
There is a primary difference between Mealy and Moore machines, which comes from the digital logic world: synchronization. In Moore machines, the output is dependent on only the current state. This means that the output changes at the clock edge when the SM transitions to a new state. This is not true for a Mealy machine. If the input changes inside a state of a Mealy machine, the output CAN change before the clock edge. Other side effects: Mealy machines typically have fewer states, but have synchronization problems when combining multiple SM's. I would say that we mostly program in a Moore-like structure: at a fairly high level, our states perform a specified function with little consideration of changing inputs. However, if your state's function (output) depends on inputs to perform, it would be a Mealy machine.
Interestingly, the state transition is the same for both Mealy and Moore machines. It can be a function of inputs and the state. However, a decision must be made on the next state. In the digital logic world, the next state logic is traditionally synchronized to the clock. This means that the next state logic can change where the state will transition up until the clock edge. This can be lost in the software world, especially when event structures and queues throw out fixed timing altogether.
I think there is a common misconception between how state machines transition and how the output is generated. The Mealy/Moore difference is really about how the output is generated, NOT how the states transition. My guess is that this confusion comes from moving a hardware defined (digital logic) concept to software. Outputs are now more than just digital bits as we have our states doing much more sophisticated things. If the function of our state depends on any kind of input, then technically it is a Mealy machine.
I see two kinks in using QSM's: 1. Event loops break regularly (this is a loose term) scheduled state transitions. 2. There are queue management issues abound. My current favorite is when one state machine has two independent idle loops. If there are two events which cause the SM to switch between loops, it is possible that the queue will grow with state transitions that will never be serviced.