Generally, in an ideal low-level language I wouldn't expect to be hampered because the language is designed for a notional abstract machine that doesn't have things like an actual stack and contiguous RAM.
Having any model at all is probably most of the value and only one part of the model (consume ordering) is unimplementable fantasy so it could have been much worse, but it's hardly a triumph for a "fundamental" language is it?
I think the machines C was conceived for are small enough by today's standards that I would not bring a high level language (like C) to the fight, a macro assembler and you'll be fine. For today's much larger machines, use Rust.
Oh you've got 16-bit addressing? Chart all the addresses and what you'll use them for on a white board or a big sheet of paper. You do not need "allocators" like malloc, that's Steve's job, Steve has a sharpie to "allocate" memory on the chart.
Yes you can statically allocate, but who wants an artificial limitation like "16 strings, 256 bytes each" when some users want 200 strings of 8 bytes and some users want 4 strings of 500 bytes. Static allocation is something you can do when your memory is large compared to your use cases.
Isn't Rust's solution mostly the same, just with C++20?
https://doc.rust-lang.org/nomicon/atomics.html
> Rust pretty blatantly just inherits the memory model for atomics from C++20.
In C this is a platform specific problem, for Unix systems you want pthreads for example while Windows provides a different arrangement.
Rust does not provide out-of-the-box structured concurrency - which I would like - but it's a lot closer to what I'd prefer here.