Nesting brackets as follows in ash does not follow the standard in bash, mksh or even busybox's hush: this=$((blah || blarg) 2>/dev/null); To better test remove the redirect for the following command (noting the space to preserve the nesting): this=$((blah || blarg) ); On any shell I've tested but ash this correctly gives error 127 for the commands grouped not being able to run. ash instead incorrectly interprets it as an arithmetic statement, presumably due to the $((, despite it not closing with )), and will hang awaiting )) or in a script will error out it missing the )).
I'm actually surprised bash looks that far into the input to determine what $(( means. hush does not do that: (unless math support is disabled,) it will interpret $(( as the start of arithmetic substitution.
Hmm, odd, you're right, I seem to have been mistaken that hush treats it differently from ash. bash and mksh however definitely do seem to be able to interpret it correctly.
It's not obvious what "correctly" is. For example, in C syntax, the longest sequence of chars which forms a valid token is taken as next token - no lookahead. In this case, this rule would see "$((" as next token.