Ok so aside from well known out of control things like another process telling the vm to brutal_kill you, cosmic arrays, or miscodes, OS interactions, oom errors or nif panics (the last three which bring down the whole VM anyways, so who cares), the crashing surface error for a BEAM process is extremely well defined.

The only no_returns otherwise are loops and hibernates. Hibernates are explicit. You might have a hard time analyzing the tail-calls to figure out an ultimate type that captures a no_return loop, but I think ignoring that condition would not be horrible for a BEAM type system (along the same lines as the random number crash scenario that I described).