Bringing this thread back for one that just bite me good, that there is no certainty in which order [receive} and [value] objects get what you send them. While I knew this, I did not understand it, I just seriously broke a massive patch with a minor edit and every attempt at fixing it just breaks things worse.
Oh yeah, that's a good one.
One [s] - multiple [r] is analogous to multiple cables coming from the same outlet. The rule of thumb that I taught in class a couple of weeks ago is -- if all of the cables or [r]s are going to cold inlets, then it's probably OK, but if any of them is hot (even one), better use [t]. E.g., in the scheduler abstraction I posted some days ago, there's one [s $0-tempo] and two [r $0-tempo]s (one for a [delay], the other for a [timer]). This is OK because "tempo," for delay and timer, updates state and doesn't trigger output (= cold). But if there's output, then I guess for safety I would have to [t ...] and have multiple [s]'s with different names.
I hadn't thought of the case of multiple objects sending to the same [value]. I can see ordering becoming thorny. (Incidentally, I added a [getvalue] into my abstraction set which will pass only "bang" into the [value] -- particularly for my sound file abstractions, the [value] objects should be read-only!)