Removing subshell from zargs (see "zargs with -P intermittently failing")

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Got my old MacBook Air (High Sierra) fired up.

With a simple shell function "f" and only "option C" of Jun-ichi's
patch applied, I can get

% zargs -n 1 -P 19 -- {1..40} -- f
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once

Removing the "wait" (without PID) from the zargs loop is confirmed to
make these go away.

As mentioned on the other thread, this should mean that the subshell
is also not needed, because the parent shell will wait for the
specific jobs spawned by zargs without blocking on other background
jobs.  I can indeed confirm that this is OK, by e.g.:

% sleep 60 &
[1] 58019
% zargs -n 1 -P 19 -- {1..40} -- f
% jobs
[1]  + running    sleep 60

However, I also intermittently get this:

% zargs -n 1 -P 19 -- {1..40} -- f
% jobs
[1]    running    sleep 60
[9]  + done       { "${call[@]}"; }

Or even this:

% zargs -n 1 -P 19 -- {1..40} -- f
%
[1]    done       sleep 60
% jobs
[9]  + done       { "${call[@]}"; }

I've seen [7],[8],[9] show up this way in a few test passes.  The
embedded "wait $j" (for PID j) does appear to have worked and returned
the correct status, so I don't know how significant this is.  Any
ideas?  It demonstrates that a job spawned by zargs can be considered
the "current" or "previous" job when the subshell is removed, which
might not be desirable.