I did ponder a separate manager, but most manager methods are perfectly fine as querysets are lazy (and we’d have to mirror queryset the same way), so at the end of the day, async variants of the execution-causing queryset methods (get, first, values, etc.) is my preferred approach.
As for attribute access, I want to reduce the scope of the work there and instead, we’ll just block it if you’re in async mode and recommend people use select_related instead. You almost always want to use that anyway these days.
save is annoying because we encourage overriding of it, but we don’t have any other choice other than to provide an async variant that’s separate - I don’t want a mixin that changes the signature as a) I believe signatures of methods should not fundamentally change in subclasses and b) we want to encourage hybrid projects as the future - sync views for the simple/safe bits, async views for the performance-critical bits.
I wish there was another option but we’re a bit hemmed in by the language design here.