Why not just add iterable.reversed(): Iterable<T> to the iterable protocol and skip on the new symbol?

[dead-claudia]

This IMHO would be much easier to use, and it would have benefits that extend beyond iteration, too.

• If it doesn't have a .reversed method, it isn't reversible. I consider that far more intuitive than this proposal.
• Arrays could implement this to return not merely an iterator, but an array. And this of course is just generally more useful, and for cases like .slice().reverse(), would provide a significant performance boost as you can use SIMD instructions to copy it in chunks. (In my experience, in perf-sensitive places, you're probably already writing a for loop anyways if you want reverse iteration, and if you really want a reverse iterator, you can just do .values().reversed(), .entries().reversed(), and so on like you'd likely already do with maps and sets.)
• Adding it to iterable iterators alongside .next() would fit with the simple non-symbol name better, and one could imagine it being initialized with shared state.
• Many userland data structures like Immutable already optimize for reversed collections by not actually copying them.

[dead-claudia]

And as this isn't going to be adding additional language semantics that use .reversed(), I don't see any risk of conflict here unless, say, someone somewhere is defining an incompatible version of Array.prototype.reversed or something.

[conartist6]

I think I misunderstood this when I first read it. I see now that we're in line.