I've looked at LUA, and it's possible I missed a flavor, but I have a long list of things I want:

  -Static types that match C for seamless interop.
  -No GC
  -First class actors 
  -Ahead of time declaration/allocation of actors and messages, with automatic async-like passing on a coroutine/actor waiting for an allocation, and automatic disposal of the actor after prolonged allocation failure.
  -Hot swapping actors from a running system in the field
  -Over the wire debugging and inspection of a running system in the field

AtomVM, an erlang VM for small devices is closer than LUA to what I'm looking for. However, I really want to create an environment made for embedded development, not try to tack a higher level runtime onto something like an ESP32 and have devices drop every 2 months from a memory leak.

I've had a similar list for embedded. Unfortunately I've yet to fit many of those criteria without relying on GC. Maybe Zim, or Nim. But then you won't get introspection.

Rust using one of the actor libraries based on async, might suit embedded really well if cross platform support matures a bit more. Rust cross-compiling requires a C linker & compiler for the target platform but Rust doesn't respect the standard environment variables for setting them using LD/CC/CXX environment variables. Though it'd be really interesting to see if anyone can setup Rust to run on an embedded WASM to allow introspection / real co-routines. IMHO, that'd be awesome.

Currently I've settled on a Forth (in Forth style, an implementation I wrote https://github.com/elcritch/forthwith/) to give me an interactive environment without GC and stable timing (important!) with ability to add C function calls readily. Interactivity is big for me in the area I'm currently working in. Forth can easily be extended to have tasks / co-routines too, though I never tried implementing them. And of course, Forth macros are like exercises in puzzle solving.

AtomVM does look interesting, but early stage. Erlang VM actually matches embedded really well. The actor model in theory lets each process run it's own GC which makes the GC model much simpler than other dynamic languages. Modern OTP is large and not suited for embedded as you mention, but pairing it down to basic actors and processes would fit well on many modern embedded MCU's. Elixir and Nerves is great for SBC/Linux embedded computing and some boards like the Omega2/Licheepi Nano. There's also GRiSP (https://www.grisp.org/) that runs BEAM on top of RTEMS.

Some of those I'm iffy on the details, but Zig (Ziglang) has async/await, static typing, and very robust ability to intermingle with C. It's being designed for systems/embedded/games.

https://ziglang.org/

Just program an FPGA. You can get all those things with https://clash-lang.org/ cause basically what you want is first order FRP and hardware does that natively. (Actor model is junk cause the interesting thing is the data/information flow not the "actors" themselves. FRP puts the focus back where it should be.)

You can implement that for embedded systems too, but as there is no obvious best way to implement it (Von Neumann machine is so different) you'll constantly get annoyed if you are the type that likes to use the weakest hardware possible as different implementations have different costs and so you'll always be second-guessing the abstraction.

need to support hot reload is one of the reasons Erlang does not have static typing

Dart has static typing, and hot reloading in its VM, so it's definitely possible.

I'm looking at hot reloading more for debugging difficult to reproduce bugs in the field than for patching critical systems which can't go down. The goal will be to hot reload logic, but not types. I think that should be doable.

seamless

Yup, the Lua interpreter is written entirely in pure ANSI C. Op should definitely see if solves his problem before implementing his own language. Unless of course he just wants to learn how to implement a language as a project by itself, in which case, have fun :).

"Also correct array indexes" is not a feature that most people feel they need to explictly specify.

Also bitwise operators, but using functions instead isn't a huge problem (and supposedly 5.3 or so fixes that).