ah, i see where you are coming from.

my notion of the whole thing was one where an actor is actually a pid (canonical or simulated), running a infinite loop with deque-process-wait on the msgq.

I understand, but it isn't enough. You have to have a selective receive primitive to write something like:

    for(;;) { // The main state.
      receive(
        when([](M1 msg1){ // Dive into another state.
          while(some_condition) {
            receive(when([](M2 msg2){...},
              when([](M7 msg7){...},
              ...);
          }
        }),
        when([](M3 msg3){...}),
        when([](M5 msg5){...}),
        ...);
    }

In that case, if you receive M2 before M1 the instance of M2 will be kept in the queue.

But if you have to write something like that:

    for(;;) { // The main state.
      auto * m = receive();
      if(m->type == M1::msg_typeid) { // Dive into another state.
        while(some_condition) {
          auto * m2 = receive();
          if(m2->type == M2::msg_typeid) {...}
          else if(m2->type == M7::msg_typeid){...}
          else if...
        }
      }
      else if(m->type == M3::msg_typeid){...}
      else if(m->type == M5::msg_typeid){...}
      else if...
    }

then you can easily lose a message by a mistake.

if you are tangling msgq-receive with its processing then sure.

however, imho, if you decouple the whole thing i.e. msgq-receive, and its processing via callbacks, then things are harder to get wrong. it might lead to either more elaborate state machine on the receiver side though, but then again imho that is not bad either.