So if you need to conditionally tick something or you want to wait for an effect to finish, etc., you're using Update() with if() statements?

The same code in a coroutine hits the same lifecycle failures as Update() anyway. You don't gain any safety by moving it to Update().

> No structured cancellation.

Call StopCoroutine with the Coroutine object returned by StartCoroutine. Of course you can just pass around a cancellation token type thing as well.

> Hidden allocation/GC from yield instructions.

Hidden how? You're calling `new` or you're not.

Instead of fighting them, you should just learn how to use coroutines. They're a lot nicer than complicated logic in Update().

Never had a crash from that. When the GameObject is destroyed, the coroutine is gone. If you're using a coroutine to manage something outside the scope of the GameObject itself, that's a problem with your own design, not the coroutine itself.

It'd be like complaining about arrays being bad because if you pass a pointer to another object, nuke the original array, then try to access the data, it'll cause an error. That's kind of... your own fault? Got to manage your data better.

Unity's own developers use them for engine code. To claim it's just something for noobs is a bit of an interesting take, since, well, the engine developers are clearly using them and I doubt they're Unity noobs. They made the engine.

I dunno, I've worked on some pretty big projects that have used lots of coroutines, and it's pretty easy to avoid all of the footguns.

I'm not advocating for the ubiquitous use of coroutines (there's a time and place), but they're like anything else: if you don't know what you're doing, you'll misuse them and cause problems. If you RTFM and understand how they work, you won't have any issues.

> Who owns it? The MonoBehaviour? The caller? The thing it captured three yields ago?

The monobehavior that invoked the routine owns it and is capable of cancelling it at typical lifecycle boundaries.

This is not a hill I would die on. There's a lot of other battles to fight when shipping a game.