I do not propose this at all. As in the main proposal, async is a keyword that transforms a function or block body so that it can suspend, and Future is a trait that lets you interact with both async-transformed functions and hand-written implementations.
Kotlin does sort of have this distinction, but it's because they use suspend funs for both generators and async/await. I discussed a design like this here but it makes the interaction between futures and iterators much harder to deal with. @withoutboats addresses this decision both in that thread and in the main RFC.
I disagree. They are supposed to be a convenient way to construct futures, but that doesn't mean they have to literally return a future when using the function call syntax.