I never made the change to first of block / first-of block, because outside of the example I ran into from porting C code... I kind of felt skeptical that variables named FIRST or SECOND were all that common. And while wanting the second or third item in a block isn't common at all (at least in my code), wanting the first item is very common.
Iterators have brought the necessity for an operator that gets the item that you are "AT", and while we could say that operation was FIRST, I think it's better to make AT an arity-1 operation. And with the idea of iterators that I'm promoting, I believe that should work on series as well.
So it seems to me with AT on the table to get the first item in a series, it's no problem to say FIRST OF or FIRST-OF ... given that you're being verbose for the sake of verbosity anyway (you could have said e.g. block.1)
But the idea of fusing iterators and series came with another thought: if you're going to update an iterator in-place to its next location without cloning the entirety of its iterator, what do you call that?
You might say "oh, you could call that ADVANCE" and it would be different from NEXT. So NEXT would make a copy of the iterator, and advance it.
That sucks a bit, because it means ADVANCE can't work on a series like BLOCK!... the position in a block is "immediate", it lives in the cell. So if you do block: [a b c] and advance block there's no way that ADVANCE can change the value held by the block variable.
This gave me the idea of letting you pass the variable in to operations like NEXT to modify them:
>> block: [a b c]
>> next block ; passed by value
== [b c]
>> block
== [a b c] ; variable unchanged
>> next $block ; passed by variable
== [b c]
>> block
== [b c] ; variable updated
That's an interesting idea, but OF doesn't sound like it changes things:
>> next of $block ; hmmm?
== [c]
>> block
>> [c]
There's no technical rule against this, at least not yet. For instance, OF is not defined as "PURE" (and it actually currently can't be, because NEXT-OF commutes the mutability of its input, and any function that does this has to be "agnostic" instead of pure).
But it's weird to have XXX-OF be something that mutates. And if you're working with iterators and have an operator like at iter, it seems like iter: next iter or next $iter are cleaner.
And Then... There's PARSE
I've suggested that series options that make it into PARSE basically just drop one argument: the parse input is implicitly the series.
This makes SKIP and AT and NEXT fairly obvious names for parse combinators that fit that.
So I feel like NEXT and BACK wind up being better as verbs, here.
What About HEAD and TAIL?
These are the only two I changed so far. They face some of the same problem if we wanted to use them as iterator operations that didn't create a copy of the iterator to seek its beginning: head $iter as an optimized version of iter: head $iter. That's weirder with head of $iter.
Maybe I've Been Thinking About It Wrong?
I have this MY operator, which is supposed to be fully generic... but maybe... it has optimizations?
What if when you wrote:
iterator: my next
It didn't turn that into iterator: next iterator by rote, but conceptually (if not implementation-wise) became something more like:
my-next $iterator
That opens the door to the idea that MY-NEXT can be implemented on top of iterator advancement, or a series variable can be updated, etc.
This seems promising, compared with the idea of operations like next $iter doing something that doesn't look like an assignment.
So a smarter MY...something that's not just a simple macro...seems like it can probably finesse making blind copies of iterators when you intend to update them. All with a nice syntax!
some-obj.some-iterator: my next ; this can be efficient!
What About "Advancing AT", then?
If MY is the device by which you can mutate things like variables in blocks while also doing iterator options in-place, that doesn't address my "AT and ADVANCE" idea:
>> block: [a b c]
>> at block
== a
>> block
== [a b c]
>> at $block
== a
>> block
== [b c]
It's a weird shorthand for at block, block: my next, which I think happens a lot. But it does obscure the reassignment, breaking from the "good" pattern set by the smarter MY.
Maybe that just needs another name. I've called it GRAB in other places.
It would be nice if GRAB could be generic, but following the same pattern as MY would be misleading because the result of the assignment isn't what you want:
>> block: [a b c d]
>> block: grab at
== a
>> block
== [b c d] ; weird because result of assignment said a
>> block: grab two
== |~[b c]~| ; antiform (splice!)
>> block
== [d] ; weird because result of assignment said [d]
GRAB could be based on multi-return 
and you could "circle" the result:
>> block: [a b c d]
>> [{} block]: grab at
== a
e.g. GRAB would look for a SET-BLOCK literally on the left, use the second item as the thing to grab, and decay to the first item. But this is all just a weird pattern for obfuscating that what's really happening is stuff like:
grab $block at
grab $block two
I think this is better done with higher level ideas, like "parse pumps" (or just iterators).
