Support for embedded bare-metal/no_OS/no_std/realtime OS hosting?

Coming from a real-time embedded/bare-metal/no-std background, I am really thinking wasi-core could benefit even finer break-up than POSIX APIs (yes, I understand core is already finer, but read on).

For systems without "fat"/general puropose OSes, for instance, threads could be unavailable, while other WASI APIs such as crypto-related APIs could exist. Another example, file systems could also be lacking, or could be very limited (e.g. a very thin layer flash-based FS), but these could be unnecessary for specific applications where sand-boxing and only particular APIs are interesting and necessary (e.g. ethernet).

Such tailored systems exist very often in the embedded space, but allowing exensibility while keeping the sand-boxing to such a system is a very attractive goal in a domain where work is continuously increasing, while requirements also get tougher.

Is there anyone else but myself interested in this topic?

In particular, I am thinking a minimal WASI environment could be implemented even on such systems, and one could develop and debug the WASM apps on some fatter system like wasmtime by restricting the available APIs to the ones available on the embedded WASI machine.

As an example, at the lowest end, a no-OS application with mbedTLS could implement a WASI environment which would allow a wasm module implemented in Rust to implement the second 2-Factor-Auth method for some system using mbedTLS primitives exposed through a wasi-crypto API.

The issue mentions wasi-core, wasmtime, wasi-crypto, Rust, and mbedTLS but names no files or tests. Start by comparing the available WASI APIs with the embedded no-OS, realtime OS, filesystem, threading, and crypto constraints described; the issue has no concrete acceptance criteria for what completion would look like.