the main problem with the .net async/await is the immediate execution of a call returning a Task, without control over where it may execute. F#'s asnyc was way saner and easier to understand in my opinion.
I'd beg to differ on the easy to understand... last time i worked with this stuff like ConfigureAwait only has cargo cults and no real good explanation, and wasn't covered in any recent version of eg. CLR via C#... Distributed tracing and thread management were totally bitten by async, also the way iterators and LINQ were broken... that was when I got off the train, as it broke the best abstractions for line of business code so that instead of designing an IO pipeline lazy developers could simple put Task.Run around blocking IO calls at the bottom of the codebas, and ... yeah, we are back at function coloring.
This brings me to: I winder for what kind of apps did you find it a delight, because for extensive data wrangling leveraging multiple calls it was a pain.
You don't need ConfigureAwait() at all in modern C# (unless you're writing desktop UI code, I don't know enough about that to comment there). In a modern ASP.NET Core web application you don't care about which thread your Task executes, there is no synchronization context at all.
I'm using C# for the backend of a web application, not legacy but .NET Core from the start.