I use Windows Terminal, you can run powershell, cmd, and even a bash shell from Window subsystem for Linux from it. As for the variation of shells, just use powershell for everything, except for some rare cases where you really need the traditional cmd.exe (are there any?)
Sorry for the OT reply of course 
The initial comparison was with PowerShell which is huge and requires the use of the .NET framework’s JIT. A shell prompt shouldn’t need the features of PowerShell for an interactive environment.
Another comparison was the need of bindings to other scripting languages like Python. Python also has a bytecode and a JIT. Some Python spin-offs can even statically compile to a native executable.
A native shell designed to replace either of the previously mentioned designs should be in the same league.
It’s not a question of “in the same league”. JITs and compiled code are not better than simple interpreted code in all cases.
When you have short running scripts or interactive commands, you want the execution to start very fast. So you don’t want to spend time compiling it (even just in time). Compilation (JIT or not) becomes useful only when you need to run the same piece of code many times. At which point, you should probably move it to C++ in Haiku’s case.
To me, a “shell” language is something to use interactively or as only the very high level control structure of a program (so, a sequence of instructions that will run once, with a few conditions and maybe the occasional loop to iterate over files in a directory or so). In that context, an interpreter will do better than a JIT, because it can start running things immediately. Less memory use, and if the code is not repeated so much, it can even be faster overall.
So, don’t jump into making structuring technical choices as the first step to answer a problem. We should first agree on what is the problem we want to solve here. I don’t know what problem PowerShell is trying to solve with JIT and compiling, because for me, that’s the opposite of what I want in a shell: code that will run once to a few hundred times, and where the cost of compiling it would not be reclaimed by executing it faster.
Ok, so reusable code should not be a thing? Will Bash still be with us? Bash is required for Posix, mostly and can’t go away without breaking changes elsewhere.
Haiku will boot just fine if you uninstall bash. So if you don’t want it, from the OS point of view, you can remove it. Some other packages will probably not be happy about it.
This has already been discussed many times. You only have to see Please make a new software for Haiku, not only a port to know what I mean.
I prefer to focus on a native shell, which is integrated with the API.
If we need POSIX support, we already have Bash, and whoever wants to use it, can use it.
If we really want to move forward, and differentiate ourselves from other operating systems (for example: any generic Linux distribution (or any other UNIX/POSIX compatible)), we have to think about projects like this.
I like the idea but the definitions need to be specified. Will GUI apps be allowed in the Haiku shell? If so, how will they be implemented?
I like your linked article even though it was just a mockup in 2011. I personally would have preferred native widgets instead of a WebView but if we need remote access like the author seemed to, a web-view with native widget bindings would be ideal. Since it runs on Node.js, it will have an optional JavaScript JIT also. That only leaves the question of “Is there anything in this article that hasn’t aged well?”
For a Haiku based implementation, what about:
Each command returns a BView that can be added to the window. For simple commands it will be a BStringView with the result. But it could be a more complex thing with images, buttonr, whatever.
It could be made to look like a chat app at start, with your requests and the replies clearly separated in chat bubbles or similar. I imagine there would be an “help” command, that would reply with a tree view of possible commands, which you can click for more details.
It could have legacy support for running executables from the path, but maybe some things would rather be done as add-ons
That sounds good for an interactive window. How about scripts?
I think a structured hierarchy of indentions could be represented by a tree gadget of commands with multiline block comments as the optional first entry per indention level. The collapse/expand buttons would act as a Scintilla-style fold indicator.
One of the things I liked about the TermView article was the way that autocomplete was integrated everywhere. Another was the way that commands were tokens rather than text.
Speaking of tokenization, does a shell script need Git support for version control? We’ll need to have a text representable save format rather than (or in addition to) a flattened structure serializer if so.
Of course.
Also, this is our opportunity to make a good scripting language, adapted to our needs.
It doesn’t need to be turing-complete. A domain-specific language (DSL) should be enough.
We can take advantage of this restriction to provide security guarantees and more powerful tools.
My idea of such a language might be something like YAML + flow control.
That may seem too restrictive, but it’s not really a problem: all the libraries and executables in Haiku are compiled, they just work. So there is no need to use a JIT or AOT shell.
The shell is just a small interpreter written in C++.
This language could be used as scripts, or as configuration files.
If it’s object-oriented C++, a more complete language can inherit from the scripting engine and provide additional features. As long as it can execute programs, query and generate attributes, do structured flow control and do interprocess communication using a “hey” command derivative, will that be a good start?
Looks interesting, yes.
Alright. Let’s consider that a minimum viable product.
As for @extrowerk ‘s “hash” name, it’s a little too close to Linux’ Bourne Again SHell name and in addition to that, it’s too difficult to pronounce the name difference in a way you can hear in a noisy convention hall. Also, it sounds like a utility for unordered maps in C++. 
If the Inc. doesn’t object to the direct use of the trademarked name, (and considering it’s system specific to Haiku, there should be no objections) I propose we have “Haiku Shell” as the name. Likewise the MIT license is the main one Haiku uses.
Once the name is agreed to and the general requirements are set, I can set up a GitHub organization. As much as I dislike Microsoft and its meddling A.I., those organizational kanban charts integrate well with team structures and a separate issue tracker and discussion boards make a deal that’s too good to pass up. As long as nothing needs to be secret…
What exactly do you mean?
I’ve always wondered why Haiku still uses the plain old Bash shell as default and not something more user-friendly like Fish,that I’ve been using on the BSDs for many years now.
TermKit looks even more promising to me,if done using native widgets.
I don’t want that even the Terminal turns into bloated Electron bullshit or something like that.
Forgetting about that for a second,TermKit otherwise looks like what a native Shell for Haiku should be: Supporting for non-power-users and simplified to make it fun and easy to work with.
I’ll closely follow that project and I’m very interested what you’ll create.
Maybe just rethink if that really needs to involve Micro$oft again 
Codeberg.org and the Forgejo software also supports Kanban boards for organizations and has issue trackers and that all,without AI nonsense and selling your soul to the devil and all that.
The bourne shell, and the TTY emulation layer simply need to die.
To emphasize this i have a long list of stuff that makes this, in my opionion, hard to use or error prone which I will highlight in it’s entirety below : )
edit: think i have more but my pc froze, and i won’t type this on my phone…
No structured formats
→ requires escape sequences (sometimes even three times, for the shell, some programm that interprets them, etc)
→ can’t differenciaate between “arguments”, “paramaters” leading to unfortunate side effects of the file “-rf” not beeing deletable unless you know the arcan invokation of “–”
→ every tool has a different syntax, dd for example, or find vs say, egrep
→ tools autodetect if you are “interactive” and wildly change their output which means there is no way to reproduce some behaviour or save it non-interactively, additional info like colors gets lost in logs
→ no way to ahead of time know what parameters will be accepted in what context (apart from “read manpage”, which is very confusing with large tools)
→ no way to properly differentiate STDERR from STDOUT when inspecting a log later,
either you loose the information what was which OR you loose the information of which log line was send after which one
→ autocompleting is hard and only accomplished heuristically, and the shell does not help at all (for example, having a “field” you can type into for different stuff, making it unescapably clear what belongs to what)
→ path names are often relative and can’t be reused in another context (that is, you the user know which path it was reffering to, but as soon as the PWD changes the computer no longer has any clue, the haiku terminal cannot differentiate anymore)
In addition to this:
→ no way for a binary to easily define additionall names that it can be called with, to expense with the need to have one binary that accepts 12 different flags to behave as different programms with the complexity that comes with that
No, we should move away from “text format” for reasons outlined above.
In addition I’m bewildered why you care what the name is now (seems an irrelevant afterthought) or why you want to setup a github org now, ugh.
We literally already have a forum here, and gerrit, and a bugtracker.
I’ve thought about designs for this possible shell for years, but i refuse to be part in any github setups to make it.
I’ve got an account there too. Maybe I should try it out! Last I checked it didn’t but it’s been a long time ago.
@Androsio
I mean the shell can be a building block to bigger programming environments. Object-oriented programming is extendable. I started looking into a visual programming language some time ago and never quite got anywhere. It was an idea that came up in this thread: Any wheels that need to be redesigned?
The issue I discovered years ago was when I was wanting to compile C# code from the regular PowerShell, which did not have access to the compiler. After a web search on the subject, I had to launch into a different shell to get access to the compiler. It’s ridiculous IMHO.