I am not sure what the balance of facetious vs serious is here. The various Unix shells have been stable for quite a while. Obviously sh is very barebones, but zsh and bash, for example, have associative arrays and other modern conveniences.
Outside of various shells, there are several other options that come to mind which do not teeter on facetiousness.
So far as I know, tcl is also quite stable.
Common Lisp is perfectly usable as a scripting language and has a very stable standard and mature libraries.
I don’t bother with python as you get into a horrendous mess with pip breaking and the v2/v3 issue.
Not every piece of code needs to serve a million people, not every piece of code needs to be sold to google, sometimes you just need code to do a simple occasional job and not change every couple of years.
Quick edit: To sibling comment's point, we're not a tech company, so it's very difficult to get this type of work done. It pretty much only happens on new development (where we are using python3), but that new development doesn't replace the old code.
https://adtmag.com/articles/2020/01/09/python-2-end-of-life....
There are current three outstanding CVEs for the latest version of Python 2. Hopefully, they'll be patched up in the upcoming release, but good luck after that.
https://www.cvedetails.com/vulnerability-list/vendor_id-1021...
Pip install? Or pip3 install? Who knows, whatever you do don’t follow the instructions s to upgrade pip as that breaks Debian and Ubuntu installs. Cpan was always a bit ropey but never this bad.
Trust me, /bin/sh is not a stable, non-moving target. Not even on GNU/Linux. Go further afield and there are a great many quirks.
Even on Linux I've encounted four major flavours of /bin/sh: Dash, Bash, Ash and Msh.
The available variable interpolation syntaxes vary considerably. The only portable way to do most string things tend to use combinations of 'echo' or 'printf' and 'sed', and even those aren't portable without some platform detection. Something as simple as adding the right number of backslashes to a command, for example to quote a command given to SSH, is tricky in shell and quite version dependent.
Bash isn't a non-moving target either; I've had Bash scripts break when moved from one Linux distro to another, due solely to different behaviours of different Bash versions.
Some of the things Autoconf does to workaround /bin/sh differences are quite exciting.
If you consider /bin/sh scripting to include the behaviour of commands run from it, which you probably should, the situation is much worse. Very standard things like 'ls', 'echo', 'cp' vary across platforms in meaningful ways.
In comparison, Perl is much more consistent across platforms and versions. If it does something in one version on any platform, it almost always does exactly the same in any later version on every platform.
I would argue that it is unfair to compare different implementations of shell, though. I think it's fair to compare across versions of bash, for example, but disingenuous to compare, e.g., Dash, Bash, Ash, and Msh. If, for example, Dash is my target, then I should call and install Dash. For this reason, it was probably a poor idea for me to call out /bin/sh, specifically, as custom dictates that this is, in fact, a different program in different environments.
One issue is that it has diverged from Lua but still shares the same name. Mainstream Lua will probably continue to be a rapidly moving target.
For the hundreds of thousands of lines of Perl 5 code at work, I expect we'll still be running Perl 5 a decade from now, and it will still be supported in maint mode by someone, if not the official Perl devs (but probably them, I suspect some will be fine just doing big fixes for the old code base).
For any new Perl project/environment, I'll just use Perl 7.
Given that 95% of CPAN supports a 15 year old version of Perl (and even Mojo supports an 8 years old version), I don't think the ecosystem is going to drop it any time soon.