There is a syntactic ambiguity between <PId expression> and <process identifier> in <destination>. If <destination> can be interpreted as a <PId expression> without violating any static conditions, it is interpreted as <PId expression> otherwise as <process identifier>. <process identifier> must denote a process, which is reachable from the originating process.
Stating a <process identifier> in <destination> indicates the destination as any existing instance of the set of process instances indicated by <process identifier>. If there exist no instances, the signal is discarded.
The values conveyed by the signal instance are the values of the actual parameters of the output. If an <expression> in <actual parameters> is omitted, no value is conveyed with the corresponding place of the signal instance, i.e. the corresponding place is "undefined".
The signal instance is then delivered to a communication path able to convey it. The set of communication paths able to convey the signal instance can be restricted by the via clause to the set of paths mentioned in the via clause.
If <destination> is <expression>, the signal instance is delivered to the process instance denoted by <expression>. If this instance does not exist or is not reachable from the originating process, the signal instance is discarded.
If <destination> is <process identifier>, the signal instance is delivered to an arbitrary instance of the process instance set denoted by <process identifier>. If no such instance exists, the signal instance is discarded.
If no <destination> is specified, the receiver is selected in two steps. First, the signal is sent to a process instance set, which can be reached by the communication paths able to convey the signal instance. This process instance set is arbitrarily chosen. Second, when the signal instance arrives at the end of the communication path, it is delivered to an arbitrary instance of the process instance set. The instance is arbitrarily selected. If no instance can be selected, the signal instance is discarded.
Note that specifying the same <channel identifier> or <signal route identifier> in the via clause of two outputs does not automatically mean that the signals are queued in the input port in the same order as the outputs are interpreted. However, order is preserved if the two signals are conveyed by identical delaying channels, or only conveyed by channels with no delay, or if the originating process or service and the destination process or service are defined within the same block.
If several pairs of (<signal identifier> <actual parameters>) are specified in an <output body> it is derived syntax for specifying a sequence of <output>s or <output area>s in the same order specified in the original <output body> each containing a single pair of (<signal identifier> <actual parameters>). The to clause and the via clause are repeated in each of the <output>s or <output area>s.
Stating via all is derived syntax for multicasting the signal via the communication paths mentioned in <via path>, so that signals are sent in the same order as <via path element>s appear in <via path>, one via each <via path element>. Multicast denotes a sequence of outputs of the same signal. The values conveyed with each of the resulting signal instances are only evaluated once before interpreting the first output, implicit variables are then used to store the values for use in each output. If same <via path element> appears several times in a <via path>, one signal is sent for each appearance.