Even POSIX sh gives you effectively gives you a stack of lists in $@, one for each function call. If you absolutely must, you can maintain proper quoting very far with those. Shell is not as limited as you think, though it can be rather inefficient about it and it's probably not a good choice for programs whose designs it isn't especially good at handling.
For whatever reason, programmers tend to be rather dismissive of non-general-purpose programming languages, or more generally languages that do not work like conventional general-purpose languages, and refuse to learn them. I think the worst case we see of this is with CSS, where people come up with elaborate ways to place boxes procedurally in javascript (and JS once suffered from being considered a toy language, too), but I've seen similar attitudes get pointed at things like apache configuration, systemd unit files, jq, and Lua.
(On the other end, sometimes people believe that they're just writing configuration, and that this is somehow more maintainable than writing code, when really they're writing code embedded in a data description language; see Chef, Ansible &c.)
As for autotools, autoconf's "Portable Shell Programming" document covers seriously ancient shells. New programs following those guidelines aren't trying to stay compatible: their code isn't going to compile on the relics that run those shells without active effort that generally isn't happening. It's just a cargo cult.
For whatever reason, programmers tend to be rather dismissive of non-general-purpose programming languages, or more generally languages that do not work like conventional general-purpose languages, and refuse to learn them. I think the worst case we see of this is with CSS, where people come up with elaborate ways to place boxes procedurally in javascript (and JS once suffered from being considered a toy language, too), but I've seen similar attitudes get pointed at things like apache configuration, systemd unit files, jq, and Lua.
(On the other end, sometimes people believe that they're just writing configuration, and that this is somehow more maintainable than writing code, when really they're writing code embedded in a data description language; see Chef, Ansible &c.)
As for autotools, autoconf's "Portable Shell Programming" document covers seriously ancient shells. New programs following those guidelines aren't trying to stay compatible: their code isn't going to compile on the relics that run those shells without active effort that generally isn't happening. It's just a cargo cult.