This system has an interesting problem that will eventually
need to be solved. I can't think of any system that has
ever fixed this. The thing that worries me is what happens
if a program sends a message to another program, but never
gets a response.

This could happen due to a bug in the server application,
or it could even just be that the program does not accept
messages. In any event, if the client waits for this
message, it will have to wait forever.

This shouldn't affect the end-user too much. If a shell
process takes too long to return, then it should quickly
say:

"This long-running process will run in the background. Type
<some-command> to poll its status."

But other programs might either decide that the program
won't take too long, or that it can't really continue until
the other program responds, so there's no point in polling.
But a bug could make both of these assumptions false,
resulting in lag.

The obviously solution would be to remove the wait
function, but many programs will see this and just decide
to poll in a loop without any timeout or error handling,
which doesn't solve the problem. Forcing the client to
specify a timeout does solve this, but on slower hardware
the timeout might not be long enough, and it is difficult
to implement.

One idea would be to give the server a timeframe of when
it's allowed to respond, and if it fails to do so in that
time, then we assume that it will never respond. This might
be possible with a really smart scheduler, but I'm not
currently able to control the scheduler. Another solution
is to heavily reconsider the current architecture, in such
a way that sending a message to a program is a function
call, and whatever the function returns must be the
response. If the message returns without responding, then
there's no response. That doesn't really solve the issue
either though, because the function could contain an
infinite loop.

For fun, let's look at the scheduler solutions. I already
have this idea that the UI process should have priority
over any other process. If we stipulate that a poll will
never respond until a frame finishes, then we can
definitely remove the wait function, and it will be obvious
that any waits blocking the UI thread are a bug.
Alternatively, we could say that a server must respond by
the end of the frame. But that would prevent several useful
classes of program.

Since package IDs are unique, I don't believe there's any
chance of a malicious program exploiting this by pretending
to be a different package. But it is still possible for a
useful package to have a long response time, which could
cause an issue. This vulnerability is not an unforgivable
sin, since every other system has this flaw as well, but it
would be nice if we could somehow prevent it at the OS
level. Then again, it's not like I'm trying to prevent
infinite loops elsewhere.