I am glad I asked. I would not have guessed this requirement. Luckily, despite one of the more stringent limitations of container.npk, it is possible to get what you want with this particular image without building a custom one from source:
I believe the actual improvement we want here was added in 7.20:
container - improved compatibility when running containers with custom "cmd" and "entrypoint" commands;
That's vaguely phrased, but experimentation shows that you can now say /container add …iperf3… cmd="-s -p 10000" and have it work as expected. You no longer have to cuddle the arguments and rely on the called command to parse them apart properly, as had been the case back to the initial version of container.npk.
I have updated my "limitations" document accordingly.
Yes. But when the Alpine container is only there to occasionally run tools like iperf3 or speedtest, then it doesn't need to run all the time (hence in my post above start-on-boot=no was specified). Whenever a command needs to be run, even ls -la, then /container run can be abused .
If there are more commands to run in one session, then /container run alpine cmd="ash", once exited, the container stops and doesn't consume any RAM.
In your doc, your right to point out file-globing "*" won't work since it does run the process you specify (and outside of a shell). But on most containers, including Alpine, you can use the sh -c 'cmd' trick:
/container/run alpine cmd="sh -c 'ls -r *'"
which does get file-globing since you invoking the shell, which then invokes the command in single quotes.