Everywhere in the C# ecosystem. You’ll see things like x.Read() and x.ReadAsync().

That sounds more like a legacy problem than a problem with the async/await model in the abstract.

If you were designing a language from the ground up, why would you implement a synchronous read operation? I would just assume that all code written in the language will treat async the way that Haskell programmers treat IO and make all IO operations async no matter what.

There’s lot of programming models that don’t require async or it’s complexity. Not everything is a web server that needs to serve 100k requests.

Because Read and ReadAsync are usually meaningfully different. There is nothing wrong with that.

See https://news.ycombinator.com/item?id=41055328

This bifurcation is mostly a concern for the standard library. It’s not something you do this way in your regular application code.

Everywhere that hard function coloring exists where the language also supports synchronous calls that do the same thing (JS doesn't support sunchronous calls for lots of things and has only soft function coloring since async is sugar for Promises, so it has two reasons why that doesn't need to happen.)