I think some really great, thought-provoking objections have been raised in this thread, which I totally love. Three things stick out to me.
Loss of Local Reasoning
There's been worry that you would no longer be able to look at a function definition and understand how it works. You cannot do this today for synchronous non-isolated functions because they inherit isolation. But I also don't see why things would change. You look at the signature and you see @concurrent or you don't. If you have this concern, can you help me understand where local information would be lost?
Cognitive Load
I think a central point of what @Alejandro_Martinez and others have brought up is, basically, it's nice to not have to think about blocking when calling non-isolated async functions. This goes hand-in-hand with local reasoning too, I think. And I agree, this is nice!
But the second you have involve state, the cognitive load goes way up today, especially if you've used non-Sendable types. It forces you to think, often quite deeply, about how you should (or even can) proceed. I'm surprised to hear others that are making use of non-isolated async functions without running into exactly these same problems.
Syntax
I think @BigZaphod's idea of modifiers on the async keyword was great, and just gets better the more I think about it. It's super-flexible! It could help with this propsoal. It could help if we opt to go a different route and just make inheritance easier. And, on top of all that, it could play well with closure isolation control. Check it out!
func runInBackground async(global) {}
func currentClosureControl(@inheritsIsolation operation: () async -> Void) {}
func newIdea(operation: () async(inherit) -> Void) {}