that seems like... unexpected behavior. I don't know how that could possibly do the right thing.
Ah. it makes sense if all the scripts are separate.
It might be good to make this configurable. Alternatively you'd have to move everything into a script file and run that... which I guess is okay.

The issue with a script file is that the resulting output would be multiple concatenated JSON strings, which is not a correct JSON string anymore. So I need to keep the commands separate and add delays in the hopes that the previous command is finished by then.

Running those in parallel is IMHO a horrible design decision.

Shouldn't cause this line the commands to run after each other?

In my case the DSL speed tests to different servers definitely run in parallel (if I don't defer them with an added delay) as the results add up to the total available bandwidth.

I'd be in favor of adding a configuration option to say whether you want them to run in parallel or not, or maybe a parallelism = n flag to say how many scripts you want to run at once, 1 being serialized.

The issue with a script file is that the resulting output would be multiple concatenated JSON strings, which is not a correct JSON string anymore. [...]

What happens if you concatenate the JSON objects (jobj1..N) like this [jobj1, jobj2, ...jobjN]? This is valid JSON and the parser should be able to handle this IMO.