@ketchupee1 Ok... found...... you put me on the path @bocanegra although maybe only because you had understood it already.
Wood for trees and all that.
Not a bug.
Always feel silly when the logic jumps off the page.
The patching fault is at [trigger]
The float is not sent to the right inlet of the [sel] because the chain reaches around and back to the trigger when there is a match...... in a loop until there is a change of float value...... and then the float that triggered the loop is sent to the right inlet of [sel] after that operation has completed (too late now).
A [pipe] after [random] breaks that chain, as does a [delay] before [random].
[pipe] insists that floats pass through in order that they arrive, holding up the loop until the first float has completed all of its operations, and [delay] holds up the chain for long enough for the second operation of [trigger] to complete first.
The loop itself is not a problem. It is that it interupts the operation of the trigger.
[golf1] works because there is no [trigger] ordering before [sel], and that was the clue....
The first float is not compared.
The following floats are.
But if a bang is sent from the left outlet of [sel] the resulting float from [random] is compared with the first of the matching floats which is now the argument of [sel] from the last float banged into its right inlet when there was no match and the [sel] operation had completed. A subsequent identical pass will of course be the same as the first and so it works fine.
Needed some time bored on a train.
Of course [delay] in this case is a bug, but we are happy to call it a feature. We perceive time as something that cannot be stopped because something that should have happened has not.
"Time waits for no man".
But the left outlet of trigger really should not fire until the right outlet has run it's course.
[delay] cheats..... saying "Yeah, OK, but........ I'll do it later.... honest", and throws the completion into the next schedule.
Just as well.