Ah! This remark highlights a fundamental difference in understanding between two camps, which I have been (painfully) aware of, but the source of this confusion has eluded me until only just right now. (Really, this is a source of frustration going back years.)

In one camp, the advice "don't use global variables" is a way of attacking a bunch of things endemic to their use, most notably unnecessary coupling to spooky state. In another camp "no global variables" is understood to mean literally that and taken no further—so you can have as much spookiness as you like, and so long as the value is not directly accessible (visible) from, say, another given piece of code appearing at the top-level ("global") context, as with the way i is bound to the activation record in this example but is not accessible outside the scope of getGetNext, then you're good.

That is, there are two aspects to variables: visibility and extent, and the first interpretation seeks to avoid the negative effects on both dimensions, while the second is satisfied by narrowly prohibiting direct visibility across boundaries.

I find the latter interpretation bizarre and completely at odds with the spirit of the exhortation for avoiding globals in the first place.

(What's worse is the the second interpretation usually goes hand in hand with the practice of making extensive use of closures, which because they are propped up as being closely associated with functions, then leads people to regretfully refer to this style as functional programming. This is a grave error—and, to repeat, totally at odds with the spirit of the thing.)