[lazulicurio]

The way I put it: .NET async makes the easy things easier and the hard things harder.

The problem is that Task/Task<T> was the foundation for async, and it's a bad foundation. Even with the ability to write your own duck-typed awaiters (and the advent of ValueTask), the widespread use of Task means if you're writing async code you're going to have a tough time getting away from it.

[UglyToad]

I think this is the crux of the matter. Since Task and the TPL predated async, iirc, people get befuddled by the parallelism Vs concurrency (if that's the correct term) parts of the Task API.

Certainly the async story is a lot more complicated in desktop but it is very simple for most server scenarios, simply put "use this async call so that the thread can do other things while you wait for the db to respond" and the model in code is much preferable to callback hell.

[lazulicurio]

IMO it's more fundamental than the parallelism v concurrency split.

Microsoft in general has a tendency to bolt on functionality in a kinda slapdash manner when another team wants it, so you get a lot of cruft that really doesn't belong in the Task class[1] but is there because someone wanted a way to handle their special case so it just got thrown into Task.

[1] See https://source.dot.net/#System.Private.CoreLib/Task.cs,045a7...