I love F#, and greatly prefer it to C# for most tasks, but I think you're overreaching a bit. C#'s dynamic feature is also extensible (via IDynamicMetaObjectProvider) and much more complete than F#'s (e.g. F# probably ought to have (?[]) and (?[]<-) operators for dynamic indexed properties). Likewise, there are several real benefits to having built-in support for async/await, such as the improved performance of a state-machine-based approach and a far better debugging story (e.g. call stacks that are async-aware).
C# is truly a great language; it was just created by people who have different priorities than you (or I) do.
You're right, you can implement interfaces for C# dynamic extension, but that won't help against existing objects. But I'm out of my league here, because every time I see an API that shows off dynamic, it boils down to saving a handful of quotes. I get the feeling F# added it just to say "yeah, what's your point?"
The benefits of built-in features you mention can be accomplished by special-casing as an optimization. Zero downside language wise, only requires some level of more resources for the compiler writers. For debugging, seems like the same amount of work; either way it has to reconstruct the "async stack". Best of both worlds, no downside.
C# is a great language, probably the best of the mainstream ones I'd say. But I still find it severely lacking in some areas, with no justification other than lack of desire/resources (type inference being the #1 case).
C# is truly a great language; it was just created by people who have different priorities than you (or I) do.