bash sometimes don't wait for children process

[Roman Rakus]

There is code in "execute_cmd.c" function "execute_command_internal":
...
#if defined (RECYCLES_PIDS)
       last_made_pid = NO_PID;
#endif
       last_pid = last_made_pid;
...
       if (already_making_children && pipe_out == NO_PIPE &&
           last_made_pid != last_pid)
         {
...
             exec_result = wait_for (last_made_pid);
         }

I'm wondering why we are doing assignment (last_pid = last_made_pid;) 
and then test it (&& last_made_pid != last_pid)?
I understand we create new child process and change last_made_pid. So, 
for example, we have last_pid 255, same as last_made_pid. Now we create 
child process and change last_made_pid to that new (256 probably). Now 
we test if they are same, they aren't and we wait for child. But what 
about situating where we have a lot of process'? 32768... last_pid will 
be 32768, make new child with pid 32769, we go through if, wait for 
child. Now we do next command, last_pid will change to 32769, create 
child, but this child will have pid 32769 and we don't go through if and 
don't wait to child.
It's done by kernel, but why is bash doing this check? Is it necessary? 
Isn't enough to check like this: if (already_making_children && pipe_out 
== NO_PIPE)? Or get a rid of #if defined (RECYCLES_PIDS) and do 
last_made_pid = NO_PID; every time? For me is better solution the 
lighter checking.