Now, you can build coroutine systems on top of procedural semantics (and trivially vice-versa) — indeed this is how many coroutine implementations are built under the hood — and since we're so used to procedural programming it's natural to assume that coroutines are a magical abstraction layer on top of procedures.

But from a strictly semantic perspective (disregarding implementation), I think coroutines are best thought of as their own distinct class of non-procedural control flow, as generalisations of procedures.

Being generalisations, coroutines provide fewer restrictions, but also fewer guarantees than procedures. So I don't think they're appropriate for all code. Specifically, coroutines kill temporal proximity guarantees: if everything is a coroutine, everything can suspend at any time (to be fair, any procedure can fail to return, but this is rarer). It's similar to exceptions in that respect.

So your point about tracking bugs is extremely relevant. With great power comes great responsibility. The current approach is to isolate coroutine functionality from the procedural core (either by very explicitly making them objects like Python generators, or by colouring them and requiring them to be executed in a context like in Kotlin). But I don't think they are quite as magical as they seem, rather just different.

(Tangential note: I've always thought it would be interesting to have a language that flipped this, and embedded procedural guarantees within an all-coroutine (or even all-continuations) semantic structure.)

There isn't really anything magical about them. They are a good way to build cooperating sequential processes.

My experience is that coroutines not only made it easier to find bugs in interrupt driven code, but it made it easier to avoid them in the first place, as the code in front of you was much easier to understand.