We've done this.

Back in the Day, it was BSD Unix, which used tcsh as the interactive shell and Bourne shell as the scripting shell, as tcsh had tab completion but has a scripting syntax which is harmful to sysadmins and other living things, and Bourne shell had a sane scripting language but no interactive functionality beyond cooked mode.

We developed Korn shell, Bourne-Again shell (bash), and, eventually, zsh to move beyond that idiotic experience. These days, our non-interactive scripting languages are Python, Perl, Ruby, and Ruby with a different mix of libraries, all of which have better FFI other support libraries than any shell does.

My point is, unless bish has Python-class libraries, I don't see the point of taking on the annoyance of having a scripting shell different from my interactive shell.

fish does make scripting so much saner. - $array just does the right thing, which bash can only approximate as "${array[@]}". This alone is worth everything. - (command) splits the output on newlines. - Block syntax is simpler, with exception of boolean composite conditions that need awkward begin ..; end wrapping - "everything is a command" syntax makes writing sometimes more verbose but reading easier. - prototyping at the command line then turning into a script is easier thanks to multi-line editing with indentation and syntax highlight.

There is however the portability factor. I've used fish as my only interactive shell for at least 5 years yet I rarely write a script complex enough to justify requiring users to have fish installed. Even when I write only for myself this sits at the back of my head and biases me to #!/bin/bash... From this perspective, "bish compiles to bash" made me immediately take note as a wise move.

That's what I was going for. Not a replacement for bash the shell, but a language that provides a bit more comfort for programmers while retaining the ability to run on any system your scripts did previously.