I'd like to add that per my own research, the reason this is impossible is because Swift Concurrency requires that all concurrency threads make forward progress, and running async code from a synchronous context implies blocking the synchronous context until the asynchronous context (which could be on the same thread or could involve awaiting other tasks/threads) completes.
Trying to skirt around the issue by introducing locks is possible, but breaks the guarantees of Swift Concurrency, thereby opening yourself up to the possibility of deadlocking the entire Swift Concurrency framework (eg. if your main-thread synchronous code starts waiting for asynchronous code off-thread that starts waiting for the now-locked main actor).
I would actually also love to see someone from the Swift Concurrency team chime in to explain clearly how we are expected to interop Swift Concurrency-based paradigms with code operating on synchronous paradigms. (cc @Douglas_Gregor perhaps?)
Actors are fantastic, but once you lock away your data in actors, any usage of this data bleeds out as async requirements into the entire code base. Very quickly, you'll find yourself in a scenario where UIKit-based code which assumes things like "finish your setup before willFinishLaunchingWithOptions or viewWillAppear completes", and trying to satisfy those requirements with Tasks appears to be nigh on impossible. With UIView.beginAnimations and UIView.commitAnimations deprecated, how do I guarantee that async @MainActor code gets to fully complete within the animation context, seeing as UIView.animate is not-async? Try as I may, I can find no good guidance from Apple or the Swift team on how we can bring these two competing requirements together.
There used to be @asyncHandler, but this got nixed, presumably in favor of just doing Task { @MainActor in ... }, but who knows.
There are discussions here about using @MainActor Tasks from these contexts, akin to DispatchQueue.async, but AFAIK they do not seem to solve the core issue, which is that doing so destroys the timing guarantees/stack context that these overrides rely on. (I'm also curious why detached tasks are recommended here rather than regular tasks which are expected to inherit the active actor, assumed to be the @MainActor?).