Alexandre,

Looking at your original question, G05.execution.order says the following:

"If you're writing to and reading from a delay line, you have to get the write sorted before the read or else you'll never get less than a block's delay."

As the others have pointed out, there are basically two ways of "getting the write sorted before the read [in the DSP chain]":

1) by accident, or in a way that can't be gleaned from looking at the patch in Pd (you'd have to take it into a text editor to see that the write was created before the read).

2) on purpose, using subpatches, which is guaranteed both to work and to be inferred from the structure of the patch.

So it's not that the idiom on the left will ALWAYS be off by a block in every instance, but that it may or may not be depending on the unreadable contingencies of how the patch was created. You can rely on this for your own stuff, but if you wanted to send it to someone, they wouldn't be able to tell those contingencies by looking at the patch, so to that user, the behavior is "undefined" in the same way that failing to use a trigger makes message execution order "undefined." The behavior is deterministic under the hood, but your user can't be expected to look under the hood. The G05.execution.order is specifically tailored to show that it can be off by a block, but there's no way to know it just by looking; it's possible a better approach would have been to have shown another one that looked exactly the same but had the other behavior, and then finally the way to make it explicit using subpatches.

====================================================

If you look at the first test patch you attached, you can tell a few things about execution precedence based on patch cords.

1) [noise~] runs before [delwrite~], [pd delay-writer], [pd delay-reader], both [+~] objects, and the [output~] abstractions, because for each of those the [noise~] feeds into it or feeds into something that feeds into it.

2) [noise~] may or may not run before [vd~], and likewise [delwrite~] may run before or after [vd~]. If [delwrite~] runs after [vd~] (because it happened to have been created after), then setting [vd~]'s delay to 0 has it reading what [delwrite~] wrote on the previous block.

3) [pd delay-writer] is guaranteed to run before [pd delay-reader] because of the patch connection between them. If you severed that connection, and then cut and pasted [pd delay-reader], it would now run before [pd delay-writer], until you reconnected the cord. You can try this and hear it change when you reconnect and disconnect the connection.

There are some cases when you actually need a block delay, and you can specify that behavior in the same way.

Yes, send~/receive~ and throw~/catch~ can be off by a block as well, but you can force them to run in sync, again using subpatches (unless it creates a DSP loop).

Matt