I guess the danger is that creators of libraries start barfing all this stuff into the interface, forcing client apps to deal with it.
But at least that lets you know which libraries you may not want to use.
Here, I'd just make the primary logging callback interface take an actor, and have an internal convenience utility method to wrap the details of calling to it. A client would very typically want logging to be serialized in any case. (If there's really a legitimate use case for a non-serialized sink, you can provide an interface for that too, but it shouldn't be the default or too prominently exposed.)
~Copyable and explicit ownership has pretty limited uses as well, and should only be used in specific situations where you really need it for something (not just because they added it to the language recently). It's really an optimization, and as such, should mostly only be used when profiling shows it's needed.
The terrifying thing for me is, even if you lever up on them, there's no safety.
A tale as old as time. You can diligently study the masters, take your time designing the perfect system, and it is pure and correct until the real world comes in.
I became a programmer and have a career thanks to iOS, but I don't think I'll ever program Swift as a daily driver again. I took it up day 1, it was a huge productivity win. But I don't expect to find myself in a situation where I need it to deploy to iOS*, and frankly, I don't want to. Oddly, Dart feels much closer to a "modern Objective-C" to me.
* beyond one-off integrations, ex. writing a implementation for the ONNX iOS CocoaPod that I talk to from another language
