[select] input types and broken "for" loops

Here is a simple counter-style "for" loop, a very common code block for metronomes and algorithms. I use these all the time. Here is a bizarre mismatch in behavior between two designs of the same code block. The only difference is in input types sent to [select].

Version 1 (left side): the for loop sends the output of [int] to a [number] object before going to [send]. Works as expected, bangs the [3] message, resets the counter and continues to countdown from 3 to 0 repeatedly.

Version 2 (right side): the output of [int] goes directly to [select]. It doesn't work, but the way it fails makes no sense. Pay attention to the order of operations in the console.

• I start the metro (toggle on), having manually pressed on the [3] message before starting the loop. (first two printouts — bang3 bang, start 1)

• It counts down from 3 to 1. (next three printouts, — int 3, int 2, into 1)

• The print order shows that [select] reads a 0 before it actually appears in the output of the [int], presumably loading a 0 into the int, so that the next time int receives a bang it should "reset," and output a zero. Instead, it goes negative in this version of the patch.

Why would these outputs be different simply because the number is between the int and select objects?