May be some orthogonality regarding %d expecting a string vs num-expr
$ a=1234 i=1
$ echo ${a:i+1}
34
$ echo ${a:$((i+1))}
34
$
Why do we have this 'offset' evaluated, you could use the same argument you
used for printf that is $((...)) is good enough, add clarity, remove
ambiguity and the docco for 'offset' could have been "a valid number"
Why printf is different?
How many people bother to write ${a:$((i+1))} when ${a:i+1} is good enough.
I am pretty sure that if printf was orthogonal with ${var:offset:length},
nobody would ever use $((...)) for %d conversion specifier.
I think the 'clarity/ambiguity' argument is not completely real, may be it
is more "to be aligned with /bin/printf" that is not able to evaluate
expressions, but if this is the reason, then bash printf has no reason to
support say %n that /bin/printf could not honor.
$ /bin/printf '123%n\n' i ; echo "i=$i"
123/bin/printf: %n: invalid conversion specification
i=3
$ printf '123%n\n' i ; echo "i=$i"
123
i=3
$
So if we admit bash printf is not /bin/printf then %d expecting a 'a string
that must be valid num-expr' instead of 'a string that must be a valid
number' is a possible deviation. Again may be with a flag... if
compatibility we xyz is a concern
