My hope is that whatever we do work on, is functionally orthogonal to bash. The bytecode is a way of making compact, fast scripting in a native language with rock-solid performance and type/error checking on-the-fly as a feature, among other benefits. However, nothing is prohibiting a compiler backend from emitting bash code and remaining entirely compatible with bash’s own features and functions.
There has been whine about bash being unapproachable, obtuse and confusing; while praise about it being particularly streamlined for the common administrative tasks - processes and jobs, files and users.
There are also other languages that compile to, or wrap around, bash - some examples are in the answers on this stackoverflow question.
Plumbum is reminiscent of the earlier Marcel example, again in Python, except this time, more “shell in python” than “python in shell”.
Also, keep in mind that we want to work on a principle of least surprise here - A skilled command wizard could hide away the panels and simplify the “coding block” UX to being little more than rich syntax highlighting; the code is entered by keyboard, and you’d never see “bytecode” manifest itself.
I feel that a robust metalanguage, whatever we do decide to work with, would go wonders to making automation and scripting accessible to both skillful systems-administrators and users with bright ideas and a tenuous grasp on the efficacies of programming.
Also, I’d like to note a particularly good example, in terms of in-interpreter documentation: The QBASIC Help system. Pressing F1 with the cursor on any keyword, drops down a window with documentation about that keyword - what it does, how to use it, relevant examples. (Microsoft made many programmers out of ordinary people, by embracing strong documentation; despite the other two E’s of “Embrace; Extend; Extinguish” having a less positive impact on the state of programming overall.)
We don’t want to gatekeep scripting to an elite force of man-page grokkers and JAPHs with six mile beards; we want to have our shell “uniquely Be” Haiku, so to speak. We’re not a UNIX, we’re not Linux; POSIX compatibility is a feature, not a function, of Haiku. (edit: see below) Though I argue we shouldn’t interfere with POSIX compatibility (yes, this means we keep Bash or zsh), Haiku is still running without it, or other UNIX/Linux staples like X11 or Dbus or hier(7) adherence, and so on.
We put the ‘start menu’ on the top right of the screen; quirky, user-friendly changes to break from “tradition” or “UNIX” are not going to hurt us, especially if it’s not exclusive against existing terminal-based shells and UI.
Really, one big change we could make, with a Be/Haiku API-connected shell, is in accessibility - to allow people on limited input or output, such as braille TTYs, to interface with otherwise GUI applications, because they follow a robust UI API with a navigable widget/window hierarchy.
(I will note - Haiku is, for all intents and purposes, a UNIX system. We don’t need to relitigate that; however, it is unique in that it breaks from tradition in compatible, but unique ways.)