Because as I've said, I'm not comparing solutions, I'm comparing problems. Rust solves the isolation problem in a completely different way. Go also solves the isolation problem by enforcing it at a language community and best practice level, rather than rigidly enforcing it in the language. Now, I personally wish it had something more like Erlang or Pony, but, at the same time... it's doing fine without it and completely satisfying my Erlang use cases in real code, better than Erlang did. Not perfectly, but fine. (I rather prefer channels as a default to Erlang's message passing, which in both my opinion and experience has the "unbounded buffer" problem in that messages can build up in a queue forever.)

Message buses solve the message passing requirement. You can get a whole range of solutions from "just sling vaguely JSON stuff around" to "here's a whole strongly typed protocol", with a whole array of options on persistence, clustering, language support, etc., a whole array of options around how synchronous they are and what guarantees they provide, rather than Erlang's one exact solution,

You're kind of demonstrating my exact point here... it isn't that the exact Erlang solution shows up in other languages, the point is that the problem space that Erlang covers is now covered in plenty of other languages, in all sorts of ways, many of them better for some task than Erlang's one point in the space that was selected very, very early in the exploration process. This was not the case 20 years ago. It is now. And I don't particularly think Erlang's coverings of the problem space are the best. People not already deep into Erlang aren't evaluating whether or not some solution is exactly like Erlang, they're evaluating whether the solution is a good solution on its own terms, and once you remove the "must be exactly like Erlang" clause there are a lot of better choices for every element of Erlang, except arguably, the integration of all of them together.