Agreed! This is horrible. How will we be able to easily distinguish calls to async functions from calls to synchronous functions? A critical difference is that when you see the await keyword, you know that a variable in the current scope could have changed asynchronously by the time you get to the next line (e.g. modified in some other part of the code in the same file asynchronously). If you remove the await keyword, you lose this critical piece of information. With synchronous functions, because the call stack is not released from one line to the next, it's not possible for a variable in the current scope to have changed behind the scenes from one line to the next.

For example, take this code:

```

let eventOccurred = false;

// Some async logic is invoked and an event listener is launched which may change the eventOccurred variable.

if (eventOccurred) { ... }

await foo();

if (eventOccurred) { ... }

```

This logic makes sense as it's possible that the eventOccurred variable has changed from one line to the next. On the other hand, it makes no sense if foo is a regular synchronous function and you remove the await keyword - Any developer reading this will think it is a bug and will delete the second if block. The await gives you a hint that the state of variables in the current scope may have changed by the time the next line is reached.

If we await by default, we won't be able to easily distinguish functions which allow concurrent scope state mutations from those which don't.