Are there any drawbacks of designing the compiler so that it can treat methods that return Task and those that don’t return Task interchangeably when it’s explicitly requested?

For intance, when declaring a port interface following Port&Adapters concept, it uncertain whether the adapter will perform any async I/O operations. Why should the internal class be involved in these implementation details of the external class?

I recognize that handling async and regular methods are very different and we can do such things as orchestrations/paralleling and cancelling Tasks. However, in numerous scenarios, orchestrations are unnecessary, and cancellations can be automatically provided by compiler assuming perhaps with some special keyword and project parameters that everything potentially can be asynchronous, but the compiler would figure out what actually is, and let us not write async Task everywhere.

Programming language could incorporate this special keyword in the interface method signature which would assume that it can return Task or not Task.

It wouldn’t force the external class return Task type if it’s not necessary by its implementation.

Are there any languages that support this? If not, then why?