Comment 3 for bug 141481

POSIX compliance is exactly the heart of this. Just because dash *claims* to comply
with the standard doesn't necessarily mean that it *actually* does. Specifically, as quoted in bug #92189, section 2.6.4 of IEEE 1003.1 states

    If the shell variable x contains a value that forms a valid integer constant, then
    the arithmetic expansions "$((x))" and "$(($x))" shall return the same value.

If dash doesn't behave this way, which it doesn't, then it is not POSIX compliant. That being said, I don't believe that POSIX requires /bin/sh to be compliant. However, the whole trend in *nix systems over the last decade or two has been to _improve_ interoperability by adhering to standards. Using a non-POSIX shell for /bin/sh clearly goes against that trend. It seems pointless to introduce these compatibility issues that require either editing an enormous number of scripts or reconfiguring systems to symlink /bin/sh to bash instead of dash just to save a few kb of disk space.

In my opinion, that is doubly so since the incompatibility is recently introduced. That is, /bin/sh _used_ to be bash, and it was (IMO gratuitously) changed in a way that created problems. The maintainers should acknowledge the error and either patch dash to actually comply with POSIX or put bash back as the default /bin/sh.