While the Mozilla layoffs were a stressful time with a lot of uncertainty involved, in the end it hasn't appeared to have had a deleterious effect on Rust development. Today the activity in the Rust repo is as high as it's ever been (https://github.com/rust-lang/rust/graphs/contributors) and the governance of the project is more organized and healthy than it's ever been (https://blog.rust-lang.org/2025/10/15/announcing-the-new-rus...). The language certainly isn't rudderless, it's just branched out beyond the RFC system (https://blog.rust-lang.org/2025/10/28/project-goals-2025h2/). RFCs are still used for major things as a form of documentation, validation, and community alignment, but doing design up-front in RFCs has turned out to be an extremely difficult process. Instead, it's evolving toward a system where major things get implemented first as experiments, whose design later guides the eventual RFC.
All major projects need to be done this way. Upfront design without any concrete feedback from a real implementation of that design will always be flawed unless incredibly simple. If anything, the next evolution of this is a process to determine which experiments are worth running to get to a point where you can come up with a sensible design. In organizations I've worked in, the first phase is known as problem framing, which quickly evolved into requirements gathering. From there you come up with several possible loosely defined designs which you pursue in parallel and then at some point, with data in hand you come back and decide on a path forward, possibly needing a few more iterations of experiments based on what you've learned. Reaching agreement early on the problem and requirements really does help the rest of the process move forward, and makes deciding on a final choice much simpler and less political.