True. In the context of this thread, note however that the risk of continued fragmentation when it comes to security enclave architecture has made Google open source a very good design in OpenTitan to woo not just deep-pocketed open source friendly chip vendors etc but also any scale of open source software shops to promote the tech. Google wouldn't go down this path unless it had very good ideas about the adoption of Rust in this space - irrespective of the scale of the entities involved and definitely considering the long-term viability of the language.
"If you're using a Cortex R microcontroller..."
I take your general point. However I think you may be cherry picking the functional safety argument. I agree that Rust has not penetrated functional safety ISO61508/ISO26262 domains and as such it will take a fair amount of work to get it at par with C. BTW there's efforts underway to solve that with Ferrous Systems' Sealed Rust initiative.
However - and this is a contentious one - most embedded software is not written to comply to safety standards compliant. A lot of the software that is bracketed under the 'embedded' umbrella is the sort of software where the use of C today is a problem from a security standpoint and that is where Rust's value is increasingly being appreciated. Does that more general embedded software require tooling that C has but Rust doesn't ? I'd say it's quite the opposite actually. Some of the packaging, distribution and updating ease that Rust has by virtue of it's top-class tooling is something that C shall likely never have - at the language level.
More specifically about Cortex-R: The Rust embedded working group has teams dedicated to Cortex-M (the most popular 'IoT' target) and the ecosystem there for bare-metal development or RTOS centric development is actually pretty rich. Try it. For Cortex-A less so but that's getting sorted slowly. There is a proposal to have a Cortex-R group now and I am confident that Cortex-R support will trend well. Again - the kind of generic tooling associated with embedded software - such as compilers, debuggers (both general and run-time specific - say for a given RTOS etc) - all of that exists already and the support for those will most certainly increase in the short term.
"If you're using 8051, a lower-end PIC, RX, RL78, RH850, 68k, etc, you don't have a compiler at all. That's a pretty dire situation..."
I don't disagree. I must confess I'm quite biased but I think the long term trend shall be towards a smaller set of more capable ISAs and from that standpoint I think things will converge towards the set of Arm, x86 and RISC-V, support for all of which exists in varying forms already - most very good. Totally agree that if you want to use a PIC etc then you the situation from a fundamental language support PoV is arguably dire. Personally I would future proof my design and move away from those processor choices on the double if I want to be connected - and even if not.
Overall the memory safety that C has thrust upon an increasingly unsafe and insecure planet is a serious problem and I haven't seen any real scalable counters to Rust from an open, expressive, feature-rich and performant PoV.