Why do you consider this a "fundamental problem" exactly?
Because there is information about the data-flow of the program that is simply not represented by what you are seeing. I consider that pretty fundamental.
However, as I said, there is the [trigger] work-around, and that's fine. I don't personally like to require these extra objects however. (Of course they are quite useful sometimes, but I don't want to be forced to use so many of them..)
I didn't mean to push people's buttons by making the faux pas of a comparison with Max, but in this respect I do find that at least Max has a deterministic way of showing what messages are going to send in what order. I consider this an improvement, but you certainly don't have to.
It's also not necessarily the *best* way this problem could be solved, because as others have suggested, too much dependence on the locations of objects creates its own issues.
Another solution might be to explicitly number the patch cords, for example. Personally I just consider that if a program is represented graphically, one should be able to take a look at this representation and figure out how it works by inspection, without having to do any testing. If the patch makes use of multiple outs from an outlet, this is simply not the case.
Steve