A (file)glob evaluates its (embedded) argument only when it is starting a new list. All values must be read before it will start over. In list context, this isn't important because you automatically get them all anyway. However, in scalar context the operator returns the next value each time it's called, or "undef" when the list has run out. As with filehandle reads, an automatic "defined" is generated when the glob occurs in the test part of a "while", because legal glob returns (e.g. a file called 0) would otherwise terminate the loop. Again, "undef" is returned only once. So if you're expecting a single value from a glob, it is much better to say

           ($file) = <blurch*>;
[download]

than

           $file = <blurch*>;
[download]

because the latter will alternate between returning a filename and returning false.

That's some pretty arcane stuff, but I think it gets the point across, which is: even though you would expect the file glob to "start fresh" each time you use it with a new string, it won't, unless it has already reached the end of a list that it built on a previous call.

As used in the OP (globbed string matches one file, glob is used in a scalar context), it takes two iterations to reach the end of the first list, and thereafter only the odd-numbered glob strings are actually processed.