Why is it misleading? If BEAM could isolate crashes in NIFs, it absolutely would. Either way the point is that you are able to leverage C code (though in Rust's case the point is just to leverage existing code, since you don't need to drop into C for performance).
Because you are not actually calling a native compiled C lib you are calling wasm code. A lot of the time you can not compile the C code to wasm and what do you do then? How do you interface with OS libraries?
You may be focusing too closely on the C aspect; the point of the demonstration in the OP is to show that Lunatic can gracefully sandbox and interoperate with any code that can be compiled to WASM, of which C code is just one example. Ideally you wouldn't need to access any OS libs from within the sandbox (indeed, much of the point of the sandbox is to provide alternatives to OS facilities), and even if you did you could still access those libs in an un-sandboxed form from within your ordinary Rust code (and yes, crashing at that point would take down the process, but it's still strictly better to have an option to run C code that doesn't take down the process when crashing).
Agreed. It's not a "foreign" function if everything is in WASM. All the VM sees is WASM code; it doesn't make a difference if it was originally written in C or Rust.
"Foreignness" is an incidental property, the actual goal is interoperation. Being able to interoperate with C code from within the sandbox is both useful and something that BEAM doesn't do. In the meantime, there's nothing preventing anyone from doing regular FFI from within the part of the Rust program that lives outside of Lunatic, if for whatever reason the sandbox is insufficient.
