One fundamental difference between C++ iterators and @rgchris's iterators is that C++ iterator instances are very light... and you're expected to be able to copy them freely (at least, the ones that iterate over standard library collections).
For instance: an array iterator is as cheap as a pointer or index. If you want to you can store iterator positions at various points in the iteration, and use them as spans (to say "I want to copy from this iterator, to that iterator")
This would be kind of like storing a new BLOCK! position as pos: next block when compared with block-iter/next that mutably changes the internal state of a "heavyweight" block iterator.
But C++ also has the ability to modify iterators in place, without creating a new one. So it can do either, and optimize the in-place case.
Ren-C has ME and MY which means that there'd be a short syntax for if you wanted to advance an iterator that only supported "make a new copy" semantics via NEXT:
some-iterator: my next ; short macro for `some-iterator: next some-iterator`
But this might not be efficient, so one might want to call the method (as C++ does) ADVANCE
iter/advance
And then NEXT could simply be a synonym for (copy iter)/advance
Then iterators could be copyable or non-copyable. If they were not copyable you'd have to use ADVANCE, and if they were you'd have the option of NEXT.
UPDATE: Another possibly-more-interesting idea is to allow NEXT to take a variable, so next $iter..which would be a light syntax that doesn't invent more words. However, this still suggests that the variable-taking form would be the "more fundamental" version, so I'm not sure how that would all sift out in terms of making the easy version to write to be the non-copying form and get the rest for free...maybe you still would do that by writing ADVANCE.