FTA: “To my personal taste, I would have strongly preferred honoring the exit signal to be optional, and subsequent superfluous yield calls being ignored and returning false.”

I think that would trigger countless issues where code keeps burning cycles, making network requests, etc. long after the code that started iteration stopped listening. Do that in a long-running process, and chances are memory usage will balloon over time.

An API with a separate “we’re done iterating now” method that defaults to a no-op might be the better choice, as it would make it easier for the runtime to figure out whether it can ruthlessly kill the coroutine (“does this object override foo” is a simpler question than “does this block of code do something other than return when any of its yield calls returns false?”)

I think however that whatever API you pick, the “run a coroutine repeatedly that may want to do clean up once it won’t further be called” will remain a source of bugs. It’s just too easy to only implement the happy path.