I'm not sure what that's supposed to solve since you want to handle error/results at that top-level `async` in your example.

For example, in Javascript, you would often just have a top-level async function and stay inside async world the whole time.

Putting your example in the middle of some random code can already be done by calling a promise but not putting the downstream code inside its .then() block.

One of the nicest things about Javascript is the absolute simplicity of its concurrency model, one of those perks coming from its single-threaded nature. I look at something like C# and Kotlin with their BYO await semantics as something I'm glad Javascript doesn't have.

I agree with this - everything should be sync first and async when needed with a keyword (similar to how Go has goroutines and channels, coincidentally this is how UNIX executables and streams traditionally worked). Javascript gets it just exactly backwards. Going from imperative to functional programming is like leveling up, and it's very hard to go back down to mutable variables, side effects and nondeterministic flow control. So I understand why Node devs prefer async how it stands now, but it's hard to unsee Go/Elixer/Erlang once it clicks.