[jacobolus]

> If there is code which is available only in async form, then it's either unusable or awkward to use at best for someone using the non-async form. And vice-versa. [...] It's a split in the code base, and extra work and complication for developers.

This is already the case today. As I pointed out, there is currently a split into about 4–5 (at least) mutually incompatible versions of I/O and network protocol related code. The new features should cut that down to 2–3, which are easier to understand and reason about, to boot.

When I say people can ignore the changes, what I really mean is: to the extent they can ignore the complexities of syntax and semantics around asynchronous code today, they can continue to do so in the future.

Alternately, having language support and a solid built-in library might encourage some people to write their code using asynchronous rather than blocking I/O, without too terribly difficult a learning curve or too much mental overhead from the new abstractions.