I think that could be made to work. And it might remove the need for
the userspace suspend-blocker API, which would be an advantage. It
could even remove the need for the opportunistic-suspend workqueue --
opportunistic suspends would be initiated by the "suspend manager"
process instead of by the kernel.
However you still have the issue of modifying the kernel drivers to
disallow opportunistic suspend if their queues are non-empty. Doing
that is more or less equivalent to implementing kernel-level suspend
blockers. (The suspend blocker approach is slightly more efficient,
because it will prevent a suspend from starting if a queue is
non-empty, instead of allowing the suspend to start and then aborting
it partway through.)
Maybe I'm missing something here... No doubt someone will point it out
if I am.