Amber doesn't have equivalent issues because bash and the utilities it uses like bc and sed are incredibly stable. I've found nontrivial shell scripts I wrote decades ago that still run entirely unchanged.
That only applies to platforms on which those utilities already run. We are talking about portability here, so that means Windows, and those utils don't run on Windows. So you're left with git bash, which isn't bash and isn't running the same utilities; and WSL, which requires installing an entire operating system.
So I ask again, why does targeting bash offer a better portability story than say the JVM?
I suspect we may have different ideas of the use case here. To me Amber is not a language I would develop an application in. I would use it in the same places I currently write bash.
Given that, my production systems are likely a big target. None of my production systems have a JVM/JRE installed, and installing one just to run shell scripts would be (IMHO) a huge increase in attack surface for little to no gain. It would also bloat the hell out of my container images.
If I'm writing a GUI application or a web server or something, then I would agree JVM is more "portable." But if I just want a script that will run equally well on Ubuntu 18.04 and Fedora 40, and across all production machines regardless of what application stack is there (node.js, ruby, python, etc), and regardless of what version of node or python or ruby is installed, Amber feels highly portable to me.
GNU and BSD tooling differs in small, but sometimes breaking ways. One example off the top of my head is that GNU sed accepts `sed -i`, but BSD requires `sed -i ''`, i.e. an empty string to tell it not to back up the existing file. Or GNU awk having sorting capabilities. Etc.
