Logged In: YES
user_id=564396
Originator: NO

hmm...

imho, [r~] should output a warning/error everytime it's communication constraint is violated:

send~/receive~ communication is by definition a 1-to-n communication: while "n" is variable (0..inf), "1" is fixed and MUST be 1.
if we have a [r~] with no matching send, the "1" is 0, and therefore an error (as pd correctly bails out)

since the communication does not take place before the audio-engine is turned on, there is no way for [r~] to check whether the communication is truely 1-to-n beforehand.

you can redirect the [r~] with the "set" message _after_ instantiation: e.g. an [r~] with an invalid receive-name can become an [r~] with a valid receive-name at runtime (and vice versa).
therefore, [r~] should bail out as soon as communication with an "illegal" [s~] is requested, which happens exactly when DSP is turned ON and the number of [s~] associated with [r~] is !=1

this is exactly what Pd does.

(btw, pd does print an error when you provide an invalid [receive~] symbol)