Currently the exit status of a command is a result<_, _>, meaning it's a boolean success or failure. That has the advantage that we don't need to think about the meanings of exit statuses across platforms, or hidden conventions between programs and their environments. However, it is more restrictive than the intersection of Unix and Windows, so we should consider supporting this intersection.

I was earlier under the impression that Windows had a convention of using error codes for exit statuses, and it appears some programs do do that, but it's not as common as I initially thought.

So the exit status space looks something like this:

0 = success
1 = generic failure
2 = custom uses in the wild
3 = abort on Windows

...various custom uses in the wild...

???-124 - Perhaps we should reserve some codes here in case Unix reserves them in the future?

125 - container failed to run (Unix)
126 - command not executable (Unix)
127 - command not found (Unix)
128 and up = program exited with signal (Unix)
256 and up = unrepresentable (Unix)

That suggests we should change the type to result<0, u8> and have the runtime trap if the u8 value is:

• 0, because success should be conveyed through the result rather than the error code
• >= 125, for reserved and unrepresentable values on Unix

Open questions:

• Should it also trap on 3, to avoid ambiguity about whether a 3 is coming from WASI or from a host Windows abort?
• Should it also trap on something like 112 <= x < 125 to reserve some room for Unix and maybe even WASI itself to define new codes?