But it is a pretty important discussion when going down to implementation details. We therefor described exactly that pattern in our book as well.

But actually I like the idea of having a phone icon instead of a message

There are systems that implement only (1), there are systems that implement only (2), there are systems that let user to choose between (1) and (2), there are systems that let user set up the expiration time for the message - setting it to zero means (1). The funniest part is that all these vendors are members of BPMN standard committee.

From pure modeling perspective I don’t think queueing is a good idea. The reason is this: if we assume queueing for messages then it’d be logical to expect the same for signals - if the process B came late to signal catcher event then it might get it from the queue just as a message. But this would be obviously a bad idea because a signal may be received anywhere - shall we keep the signal in the queue forever? Therefore signals must be synchronous; messages should better too for the sake of consistent behaviors of messages and signals.

Communication via data is of limited use here because it doesn’t generate an event. Well there is a conditional event in theory but I didn’t see it implemented in a process engine yet.

Sure it’s the best solution.

Sometimes the genius of the “and” is the right answer