Maybe it's "conceptionally" the same but it's not actually the same. That's kind of more important. But code written for the Bourne shell ought to and does work in any of them -- but might not work in your "shell" because your extensions break compatibility with basic, basic, basic Bourne shell features. Pick something else. It changes the meaning of existing code and existing variables, that's how. Even worse, it does it implicitly. It also completely changes the language from a weakly typed one into some bizarre mixture of weak and strong types.

Perl has a lot of advantages but the way it handles variables can be quite annoying. Try and print something and get ARRAY0x00000000 all over the place because you forgot what type your variable was, or some fancy library's documentation forgot to tell you what to expect, but because the language was derived from the weakly-typed AWK language there's mechanisms in place to bonk you on the head when you use a list as an array or a hash as a reference or etc etc etc. Imagine that in a shell. Current shells do a fairly good job of combining everything under the umbrella of "string". If you start adding variables that have no sensible meanings as strings, a Perl-like mess is what you get. It's one of the most important features of the shell and a fundamental part of how inter-process communication works in a shell. It's very powerful even if you don't think you need it. If you don't want it, you don't have to use a shell language.

I don't think you're really reading what I'm writing here.