I had a bit of a brainstorm...
If we were to say BLOCK!s themselves could be iterated as-is we get something interesting, where @iter acts as a synonym for iter.1 and @iter: as a synonym for iter.1:
>> iter: [a b c]
>> @iter
== a
>> iter/next
== [b c]
>> @iter: <magic>
== <magic>
>> head of iter
== [a <magic> c]
On the surface that looks pretty cool. @iter is notably less expensive than iter.1 (more compact, better locality direct in-Cell). And the theoretical performance and benefit of it is just more favorable.
But there's a devil in the details of how things like iter/next could work. If you were going to update such an iterator, then the iterator update must operate directly on a variable. You can't calculate a BLOCK! used as an iterator, only calculate the name of an iterator variable, because the index portion is an immediate value.
I don't know if this kills the idea, or if "immediate iterators" are something that could be accommodated. Does it imply something architecturally about iterators in general?
When thinking about the BLOCK! possibility of being the iterator, it made me reflect on how it's not a GET/SET of the iterator, it's a GET/SET of the @iterator.
e.g. when you SET a BLOCK!, that's a multi-return unpacking.
>> x: y: ~
>> block: [x y]
>> set block pack [1 2]
== \~['1 '2]~\ ; antiform (pack!)
>> x
== 1
>> y
== 2
This generally points to an idea that @iter: foo doesn't mean set iter foo.
I think it means set the @iter foo.
This goes along with other things I've been saying, but wanted to just kind of point out some more supportive reasoning.