Given that I decided to go a middle ground and use Nim with its new ARC (GC reference counting and move semantics). In theory it's less efficient than compile time Rust memory management but it works well in practice. Wrapping the C API is trivial and handles all of the C defines as well as writing in C, since it compiles down to it. And you can use any Nim or C libraries. It's surprisingly effective!
Except you still get data races from the C API's which Rust would likely help prevent. So it's cool to see someone toying with an xtensa llvm backend. I wish LLVM still fully supported a C backend so you could compile Rust to C and build that. Hopefully in the long run, more native rust libraries will exist for more full functionality embedded.
Rust might just be a leap too big and can only work in blank-slate scenarios.
"There is no hidden control flow, no hidden memory allocations, no preprocessor, and no macros."
Its very tempting to try this due to the huge amount of resources the hardware has, but it is a huge amount of work. Just being able to access the registers isn't very valuable, the ESP is about Wifi, BT and I2S. If there are no ergonomic Rust APIs for those, why even bother?