So, @jens, when you implemented NUMBERS as a primitive we had a brief conversation (in my home office, I'm pretty sure) about this in which you asked what the Tools version did, and I said it returned an empty list in that case.
To tell you the truth, I now think that my Tools implementation of FOR was a mistake, and it shouldn't work backward either. We could instead give a really specific error message with a suggested rewriting. I wrote FOR the way I did because I wanted to show off assigning a ringed predicate expression to a variable so the loop code could be IF CALL (ENDTEST)) ... but with FOR primitive, that reason no longer applies. :~)
But, @milliones, your examples all look strange to me because you're applying FOR EACH to the NUMBERS list rather than to the list you're really interested in. It helps that you change the name of the upvar from ITEM to INDEX, but it'd be much better not to use FOR EACH at all, and instead we find a way to do it functionally.
So, @jens, how about if the ring in MAP, KEEP, and FOR EACH (but not COMBINE) automatically generates names ITEM, INDEX, and LIST (or DATA, which I have mostly been using since a student complained that an orange LIST variable block looks too much like a red empty LIST block) for the first three formal parameters? That would make this super-undiscoverable feature a little easier to grok. (If the user drops a ring that already has formal parameters into that slot, though, use the user's names.)
That would mean we have to promote this obscure bit of syntax into a part of the curricula. (Remember, the TEALS intro course is meant to be prior to CSP, so TEALS and BJC would both use this.) I'm not sure I like that idea, but whether we add this to the curriculum or not, I still vote for using the meaningful names as the formal parameters if any.
(At this moment I'm toying with the idea that we include ITEM as a visible formal parameter in the HOFs, and users could click right for more choices or click left for empty slot filling. But I don't really like it. I'd almost rather have a per-user setting to start with 0 or 3 formal params.)
By the way, the Official Correct Way to implement INCREASING? is to load the list operations library (the second one in the Libraries list) and use a two-list MAP:
This takes some wrapping your head around, but it has the great virtue that it doesn't use list indices at all, which is the right way to think about lists.
(@jens: If the primitive COMBINE knew about the base cases for the Only Six Blocks You Ever Use With Combine, then the IF special case here wouldn't be necessary. MAP would report an empty list, and COMBINE would report True, which is the base case for AND.)
But, @milliones, back to reality, I'm tempted to say that if you're looking at indices in FOR EACH, you might as well just use a FOR, and not have to use NUMBERS at all. Our big push is on using functional programming where it's appropriate, and both ODD-ITEMS and INCREASING? are functions, so the goal is not to have to use commands (such as FOR and FOR EACH, and the things you'd do inside their input scripts) altogether. That's why the recursive versions, and my two-list MAP version, and Jens's ITEM/INDEX/LIST inputs versions, are preferable, imho. (And, yes, this puts us at odds with the CSP Framework, but in BJC we do the render-unto-Caesar thing by saying "by the way, on the exam they'll want you to recognize this ugly way to do it.")
This is probably more advice than either of you wanted!