There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a switch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This switch was introduced to always enforce a strict order between view, unblock and message M.

If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.