That's not new at all. This is known as cooperative multitasking, and you have the system define places where a co-routine switches to another one waiting for CPU. These points are usually those at which I/O is done. Not at all new.
I'm not sure what you mean by "system" here, but if the OS does it then the architecture is probably not cooperative, but rather preemptive. On the other hand, if the runtime (such as the Go runtime) causes a context switch between coroutines because one of the coroutines is waiting (on blocking I/O, etc.), then the architecture could still be considered cooperative because the scheduling is such that none of the coroutines would ever be actually preempted by the runtime while executing instructions. Of course, they could still be pre-empted by the OS because they're ultimately all running as system threads, which is one of the downsides of all this: eventually, it all comes back to threads, how many of them are present, and how the OS handles them.
I didn’t claim it was new, I claimed it was different from typical coroutine implementations where you need to explicitly yield (all coroutines are cooperative multitasking by definition). I also claimed that this gives the usability properties of threads (you claimed that coroutines are somewhere between threads and callback hell WRT ease of use, which is true for traditional coroutines but not for goroutines. Another important distinction is that traditionally coroutines are not M:N, while goroutines are.
