It wouldn't. That's literally what coroutines are. In-process, lightweight, cooperative multitasking, built in as a language feature (or at least close enough to it).
It is not. Coroutines are a much more fundamental feature. They can be used to implement cooperative multitasking, and since that is such a common use case, they have gotten confused with the concept of cooperative multitasking.
Actual coroutines are a lot more flexible and interesting than just cooperative multitasking, though.
Erm, I'm pretty sure I can implement coroutines using cooperative multitasking. Also, the other way around. So I'd say they're equivalent in that sense.
Now you're really just making claims about implementation details. That doesn't make one concept more "fundamental" or "flexible" than the other, while "interesting" is just a subjective judgement.
I'm not. The scheduler decides what code to execute next, the caller does not. With coroutines, the caller explicitly decides what code to execute next. That's a fundamental difference.
Explicitly selecting what code to execute next can be trivially achieved in a cooperative multitasking system. Naturally, the details work out differently. That's because both concepts are equivalent, just not the same.
Actual coroutines are a lot more flexible and interesting than just cooperative multitasking, though.