Thats not completely accurate. When people talk about Erlang they are talking about two different things at the same time.
1. Erlang the functional language with a syntax inspired by prolog.
2. OTP and the Erlang Runtime.
The first one is an annoyance you grow to tolerate and sometimes even love. The second one makes you a fan the first time you actually need fault tolerance. Elixer gives you the second one and arguably improves on the issues with the first one. All of which to say "Its more nuanced than you seem to want to make it".
The distinction between language and runtime is right.
I would disagree that Elixir improves issues of Erlang. I see it as plainly different, not a newer, better language on the Erlang VM.
It does have the benefit of avoiding a few mistakes Erlang made (order of arguments in the standard library, for example), but for the vast majority of the time I spend developing in Erlang, that's a very minor part of it.
The design objectives and decisions of the languages, the general tooling given (i.e. macros), and the approach the community takes to development has a much greater impact into how systems are shaped and built than the actual objective improvements they have done past Erlang mistakes that are the results of 25 years of existence, sealed in place through backwards compatibility promises.
These are often not improvements, just a different way of doing it, and whether it's better or not will absolutely depend on the task at hand.
Item #1 is arguably a subjective thing to measure. When I say Elixir improves on it I mean in the sense that it appeals to the general populace more and therefor has a greater chance of gaining popularity.
On another note, I disagree with calling the Elixir syntax elegant, but that's purely a matter of taste at this point.