@jameslo Fascinating......... and very annoying. I think I will need to sleep on it.
Yes. The subpatch is behaving in exactly the same way as you described for the patch in your op.
So going back to your table. The head of the chain...... the source... must be created after the [receive~].
It is not the order in which we naturally create a patch.
It is unintuitive and I think you might be right to say it is wrong.
It is not a new "feature". It is the same in extended.
David.

@jameslo I agree. I did report a bug once, but have never dared ask a question on the list.
The list is the domain of those creating Pd. I often read what they have to say, but I would not dare to show my face.
David.

@jameslo It looks like the delay is actually in the send/receive pair maybe because the write to buffer needs to be first but the send cannot be properly written without a matching receive.
Maybe writing [phasor~] afterwards simply forces a chain renewal (as you said.... because it is further up the chain) and thus a correction of the order.
Putting them in a subpatch does force execution order correctly even with [phasor~] created first.
So it looks like using a subpatch for buffer write/read pairs is a more than a golden rule...... golden.zip
[phasor~] created first in both patches.

In extended there was a link to G05-execution-order.pd in the [send~-help] file......
David.

@jameslo I think it is because when the audio chain is built [s~ next] and [r~ next] will no longer exist.
So I would ask in what order were the cords connected...... but that is probably irrelevant.
Does [-~] need to receive on its right inlet first to do the calc and waits until the samples arrive?
So when "3" is not yet processed [s~ next} and [r~ next] are resolved and the connection is made to [-~] and then to "3" so no latency.
If [phasor~] is created first then its connection to the left inlet of [-~] will be first and so you have latency?
I hope that makes sense.
You could test by reversing ith connections to the inlets of [-~].
David.

@ingox OK..... you win.
David.

@ingox Ha ha....!!.... for the first time....... EVER...... you have posted a MORE complicated and less elegant solution.....
David.

@cfry You can insert the integer into the symbol like this.......
David.

@jameslo Yes, that is less expensive...... good catch......
I had simply assumed it would not work because of the spaces...... but of course the second inlet is handy.
David

@buzzelljason You can add a line to the Pd window Menu... File.... Preferences.... Path....... that points to the Extra/mediasettings folder and then it will work anywhere.
David.

@buzzelljason Yes. Well. Everything sent by a control rate object is a message.
The messages can be floats or symbols or lists.
Lists are a list comprising floats or symbols or a mixture of the two.
Items (atoms) in a list are separated by spaces.
It gets complicated.
If the first atom in the list is a float then the "list" tag is automatically applied, and then is silently ignored and dropped as it passes through the next object (except for [route list symbol float].......)
If the first atom in the list is a symbol then that symbol becomes the tag.... the list header..... and the list can be routed by that tag. But if the list passes through a [list] object then "list" is added (prepended) as the header. That is why [list trim] is used almost everywhere after a [list] object...... to remove the header and then be able to [route] by the original tag (if it was a symbol).

HINT.. If you install the Zexy library then [rawprint] shows you whether an atom is a "tag", 'symbol' or float....
Trying to work with vanilla OSC objects can be just guesswork without [rawprint].
mmm.pd

The messages arrive from [audiosettings] as a list which is a mixture of floats and symbols........ but the first atom is a symbol and there is no "list" tag.
[listdevices( returns a series of messages..... they are lists...... with the first atom "device"
That is why "device"....... a symbol.... and "0" or "1" can be routed. "1" could not be routed by [route 0 1] unless it is a float and "device" could not be routed by [route device] unless it is a symbol.

The device name is a symbol........ it can only be sent on in one hit because it is a symbol...... if it were a list then each part would be sent separately as a space normally "means" "next item".
But once it has passed through [route 0 1] it has lost its "symbol" tag. That can be put back by passing it through [symbol].

So the problem for [list-compare] is to create a symbol that is identical. Not easy as a message with component symbols will be treated as a list. Fortunately @ingox gave us a vanilla solution.... [concat].
And then of course to turn them both into lists for the comparison.

This will work........ this.zip
It can probably be simplified (and certainly @ingox will shortly post a more elegant solution.... ).
David.