Rust is pretty fresh and really innovated a lot with its actual safe-by-default approach in a non-managed language actually able to replace C and C++.
Most new languages aren't a Rust, but just a Python (yet another low-performance language assuming you don't actually need strong typing to realize later that actually, you do). But a Python is definitely easier to get started with than a Rust (or the footgun languages, it is able to replace). So there is definitely a use case for that too.
Go is a good case of a young system application language designed for simplicity.
And everyone creates a domain specific language once in a while. Those can make specific tasks a lot easier.

Programming languages don't really look like they are a solved problem. It seems like everything gravitates to Hindley Milner over time. But mainstream languages finally adopting null-checking at compile time by default and language features for parallel execution reaching the mainstream are recent enough that I think, there might still be a long way to go.
And obviously, you want AI to code in a language which is as much deterministically compile-time-checked as possible because of the hallucination problem (which btw, is also present in humans; the technical term there is brain fart). I expect that to be something which requires writing actual mathematical proofs like one does in Coq solely because AI doesn't try to kill you if you insist on it writing mathematical proofs for everything.
The scaling limit already is the humans who have to do the code review. So any language which makes more bugs more obvious before the code reaches the review stage is extremely valuable even if writing code in it is a real PITA for humans (as long as they can read it, it's fine).

All you've demonstrated with this comment is your lack of imagination.

I think there are programming paradigms that haven't even been discovered yet. Rock music was "discovered" centuries after baroque music, and composers back then would have thought baroque music is the ultimate musical genre, which could not have been improved upon.

I've been working on a programming language recently that sort of programs itself. It's hard to explain how it works, since I approached it from a mathematical direction, but for a domain and range defined with a set of correct input-output pairs, there are an infinite number of functions which correctly maps one input to its corresponding output. If we define f_1 as all functions which correctly map the first IO pair, f_2 as functions which correctly map the second IO pair... Etc etc until we reach f_N, then the set intersection of all f_1...f_N is the set off all functions which satisfy our requirements. From this set of known correct functions, we can sort them by speed or some other trait.

But the devil's in the details there. I won't go into how I get f_1...f_N, but I'm having fun thinking about it & designing it. It may even be useful some day.

I want a language with an internal/core calculus of GRTT with a specific grading that I believe will provide both optimal evaluation and prompt resource release. You aren't going to get that by building on top of another language.

Of course you could do it as a library for another language, but the few values you could lift/lower and the necessary analysis do to bidirectional type inference/checking mean that you are writing a compile phase whether you call it that or not. In theory, you might save on the tokenizer/parser, but those are trivial to write. You might be able to reuse parts of the API/ABI, which could be an advantage if the underlying language has a good, stable one that can reflect your linking/calling/passing restrictions; but that's not likely.