If we do this, we would need to change all the callers to also be async. We can't cause a build problem after. This means cascade into several parts of the program. This is a huge task.
I actually like it.
Using .Result is ok in several situations, when you can control the program flow. A console app that is calling into an async only API will have to .Result, for example.
Also, it would be a good idea to rename the function to end with Async.

Because of the cascading problem, I think we need to discuss it.

Yes, this can introduce a huge change to the solution. Some functions can not be made async - for example, Main in console applications. Also, async event handlers that return void could crash the process with unhandled exceptions.

The more I think about this concept, the more I like it, too. After all, turning a program async is a pragmatic and menial task.

If the method is already async and still uses task.Result, we could add a warning and provide code fix which converts the task.Result to await task

I think this would be fair. This way, we won't cascade the conversion to async and introduce massive build errors.
It won't catch deadlocks caused by async method calling non-async method with .Result, but I think it would be a good start.
I can take a shot at implementing it if everyone is ok with this.

@AmadeusW I am ok with it, as long as the method already has the modifier async. So we can't change an async method that returns a Task directly, ok?
Later we can evolve this to be more ambitious and solve the original problem.
Go for the implementation, then, @AmadeusW.

@giggio @ElemarJR @carloscds pinging you because the guidelines say that I should notify you before creating a PR.
I think I've got it working. Check it out at master...AmadeusW:0122
Screenshot of a non trivial case: