Simple example: using current shells it is not convenient to work with API call results which are structured data. Yes, there is jq but if the shell had data structures it would be much better, wouldn't it?
On UNIX, the "API" is basically that everything is a file and programs are written to handle text streams. After all these years, the shell is still perfect for this.
It sounds like you want create a new language and shell in order to have something similar to Windows PowerShell which interacts .NET objects using its API. This does not fit into the Unix "API" described above. This isn't a "Next Generation UNIX Shell" but an alternative shell that suits a certain group of users who don't really understand UNIX.
That's great, but how much data do you work with, day-to-day, that is best represented as text streams? For me, the answer is "virtually none". Heck, most of the stuff I work with, day-to-day, can't even be represented meaningfully in a text stream. (Editing video, for example.)
For me, the answer is "plenty", but that's neither here or there. Everyone has their own use case and I daren't say yours isn't valid.
Video editing tends to done in applications, of course that's not to say video data can't already be piped. I once set up a screencast using gstreamer to convert /dev/video to an HTML 5 compatible video format which I then redirected to a named pipe which could then be opened from a HTML file page in a web browser. The UNIX shell is already very powerful. You haven't stated what it is you want to do with video editing that is either difficult or not currently possible but would be possible with this new shell, so I'm not sure that I really understand the point that you are trying to make.
There is nothing wrong with creating an alternative shell. I can see the need for something like this. PowerShell for example works very well. My main gripe with this project is that the author has named it "Next generation UNIX shell" which suggests that it is intended to be a replacement rather than an alternative. In my humble opinion, it tosses the simplicity out of the window that makes UNIX, UNIX.
To quote Dennis Ritchie, "UNIX is simple. It just takes a genius to understand its simplicity." I'm no genius, but I get it.
It is more that unix shells are built on piping and piping is systematically broken in unix shells. It just becomes extremely obvious after using for powershell for any time which doesn't require most of the work to scrap and rewrite ouput to make it compatible withan other program.
Doing piping well is extremely hard and basically requires that all commands give metadata about their arguments but doing it better wouldn't be all that hard.
You could do the same thing with text streams but structured piping would be a lot harder. If all programs would read and write something like json or msgpack and have a unified argument parser and dumper working with the shell would be a lot easier and faster.
I'm not really sure what you mean when you say "piping is systematically broken". It sounds like you might be trying do something that isn't really meant for piping. The general idea behind UNIX programming is that projects should be broken down into small, simple programs that rather than overly complex monolithic programs[1][2].
It sounds like you want create a new language and shell in order to have something similar to Windows PowerShell which interacts .NET objects using its API. This does not fit into the Unix "API" described above. This isn't a "Next Generation UNIX Shell" but an alternative shell that suits a certain group of users who don't really understand UNIX.