In the end it comes down to healthy competition, it doesn't matter much why one thing is better than another, it just has to be preferred by enough people. And all those people may have different opinions on why they would choose one language over another. Traditionally, there has been a real lack of "better C" languages. Now since a few years we suddenly have a number of promising options but still not enough: Odin, Zig, Jai, and a few lesser known like C2 and C3, that's about it - I count Rust and D as attempts to a "better C++", not a "better C" (I'm aware of D's "das better C" subset though).
Apparently Jai is specifically tailored to game development problems and frustration with C++ for game dev (or at least it tries to fix rough edges that a typical game developer encounters in existing languages used for game dev) - whether that is actually true I can't tell though since I haven't used Jai yet.
> Now since a few years we suddenly have a number of promising options but still not enough
Well, but how do you recognize that there are still not enough options? I assume it should be a bit more specific than just a feeling or "personal preference", isn't it?
> Rust and D as attempts to a "better C++"
Rust has at least one big unique selling point which was not present so far in any other language (at least I'm not aware of any one): compile time automatic memory management. The unique selling point of D in contrast is not that obvious, at least not to me.
> whether that is actually true I can't tell though since I haven't used Jai yet.
> how do you recognize that there are still not enough options
One language that's still missing is a simple C-like language that offers Rust-style memory safety but without Rust's design philosophy of repeating every C++ mistake (that's not about memory safety) and high level type system wankery (or generally too much influence from functional languages).
There are also many more areas still to explore when it comes to memory safety that are less extreme than Rust's approach (I completely forgot about Vale which tries out some really interesting things in that direction: https://vale.dev/)
It would most likely need to 'break' C in a way that it wouldn't be recognisable as C anymore or at least break compatibility with existing C code (e.g. removing pointers, or at least pointer arithmetics, and the way pointers and arrays interact).
Not necessarily; the compiler has to trace ownership anyway and could also detect "legal" use of pointers and reject certain uses for objects under the "borrow checker regime", as Rust does it. But of course one could take a subset of C and augment it with the new features, as it was e.g. done in C++ in the eighties or Simula (with Algol) in the sixties; the obvious advantage is the similarity to the original language and (potential) reusability of a large existing code base.
> Traditionally, there has been a real lack of "better C" languages.
There never has been. There has been a lack of really successfull C alternatives for some time (after everything that wasn't unixish or Windows died, except for MacOS and Objective-C) - and still is. Rust is still less used than Pascal has been 30 years ago.
Apparently Jai is specifically tailored to game development problems and frustration with C++ for game dev (or at least it tries to fix rough edges that a typical game developer encounters in existing languages used for game dev) - whether that is actually true I can't tell though since I haven't used Jai yet.