Another classic one we keep getting for Asahi: "When are you going to support proper suspend instead of s2idle?"
That is the wrong question to ask. You don't care about that. You care about battery life during suspend, and we have to fix that first, and the way we fix that is by improving idle power consumption, which is important while the system is awake anyway (but not as important, because display power dominates idle power when the screen is on already anyway).
After we have system idle power consumption down to macOS levels we'll worry about deeper suspend states, if it's worth it at all at that point.
All of this is irrelevant to you, the user. You don't care how suspend is implemented. You only care about power consumption and battery runtime during suspend. The underlying implementation is for us to worry about, not you.
As for improving idle PM? If we knew how to do it, we'd have done it already. Fixing PM with no documentation is a game of trial and error. You do "more things" like macOS and hope that one of them reduces power consumption. We do have some ideas and things to try, and some approaches to investigating this further. There are definitely some components that don't have idle PM yet, but it's also highly unclear if implementing it would improve anything measurably, because it seems unlikely the things we do know about have much of an impact. It definitely isn't obvious what we're missing, and we don't know what the real answer is going to be. If we did, it would already be fixed.
(Of course, I know why people whine about s2idle: Because it has a terrible reputation on Intel. As usual, any experiences you might have had on Intel platforms are completely irrelevant to Apple Silicon.)
@marcan
I guess the way to improve the linux power consumption is UnifiedPush adoption.
When multiple apps reside in memory and periodically ping this and that - I can't imagine it being good for power. Meanwhile UnifiedPush means one app listening one socket and waking up other apps if needed. Smartphones work like that (via google mobile services and its Apple equivalent), and I bet macOS too.
So this might be userspace, not drivers problem.