I don't honestly find the pain point to shell scripting languages, in terms of programming them, to be that they don't look enough like 'real' programming languages. I think that on a basic level the way that posix shells work is quite natural for the tasks they're expected to perform. There's even a certain elegance to things like [ being (potentially) a program that behaves as any other would.
It is quite primitive as languages go, though, and has some ugly quirks, but I think it's a mistake to look at it and say it needs to be changed to be more like things not designed to treat running programs as primitives. I'd rather see something from someone who said "bash is great but could be so much better!" than someone who said "bash is TEERRRRRUUUBLE and we must replace it!"
That said what I want so much more than a new shell is one that isn't stuck letting me only reason about the machine I'm logged in on. There's been a few things that call themselves distributed shells, but they're really more orchestration tools.
Shells are what people use every day, so it's tempting to make more out of it. grep, sed and awk are clumsy tools, but they are more "within the reach" than python or ruby.
Also, you miss one particularly elegant aspect of shell programming: the pipeline. It's a powerful facility of concatenative programming, but most people haven't realize it. Try to write "find . -name '*.py' | xargs cat | wc -l" in other languages. You end up either with some parentheses or intermediate variables or a loop, and in any case, much longer code.
import pipe\n find(name='*.py') | xargs(cat) | wc().lines\n
\nThe implementation of the functions is left as an exercise for the reader, but the syntax is valid.