> because if you suspend anything you'll get deadlocks if anything else calls it
Processes do not call other processes, and nothing in userspace can make a (non-buggy) kernel deadlock. Processes could be waiting on IPC or user-space coordination like file locks, but we don't care about the normal user-space - our special process would not take file locks or try to IPC with other processes, as it's designed for this use-case.
> or memory growth if anything else sends IPC to it that gets buffered.
When you send something on a pipe, the sending process stops executing and the receiving process becomes runnable and eventually scheduled to read the data. The sending side will not get scheduled again until the receiving side completed the read.
For anything buffered the same happens once the buffer fills. Nothing will grow unbounded, and behavior when other user-space applications do not run is perfectly well-defined and a constantly exercised.
After all, remember that processes only get to run occasionally if at the start of a scheduling epoch the kernel feels like it, they are preempted at random mid execution, they are delayed by other things (including realtime processes that can delay other things indefinitely, higher priorities, other niceness, CPU quotas, whatnot), and so on. The idea of continuous process execution is a very, very rough illusion.
What this would take is basically just something to make the scheduler disregard most processes that are technically runnable in this semi-suspend state, only picking kernel threads and specially marked processes.