"you shouldn't have unwraps in production code" is exactly the same form of argument as "you shouldn't be assuming crypt returns a valid non-null pointer in production code".
And that analogous situation can happen in the safer language where crypt returns an Optional(String) which some bad programs assume is always present. You don't know where all such programs exist, and people use them who don't have the code and cannot fix them.
Returning an error token which is carefully different from crypt's second argument was an attempt to fix programs that cannot be hunted down, patched and recompiled, even if fixing them would be easy to do.
Of course the tooling for C pointers being null or not is not comparable to optional types; that's not debatable.
Once again, no, because these unknown programs would just crash on the `.unwrap()`; not get in a silently corrupted state. Same causes, different effects.
Note that even on systems that don't have hardware support for trapping null pointers, it can be implemented in the compiler as a code generation option.
For instance, in 1987, Microsoft Quick C introduced the /Zr option for doing this, as well as a #pragma check_pointer({on|off}).
If you're interested, BitSavers has the documentation: https://bitsavers.trailing-edge.com/pdf/microsoft/msdos_c/qu... Look for section 8.1.4.4 and also /Zr.