If the original setup.exe is spawning another process, then terminating and returning a result code, there's not much you can do to manage that scenario. Even if you did use something sleep.exe, you'd still be guesstimating what the delay time should be, and there's always a possibility that it comes up too short and wreaks havoc on the installation. Plus you have the VBS script
Another option ... possibly ... is to break those several subordinate installers out into their own individual packages, document any dependencies by defining prerequisite rules in the package definition, and then have the packages install sequentially. This is just as complex as other solutions though, and has it's own risks and pitfalls.
A third way it might work, if you can break the subordinate installers out (and they have a way to not automatically spawn the next installer), is to tag them all as postinstallation Run Program events in PackageBoot that are tied to the previous via return codes and continue-on-success constraints, with some benign or 'administrative' task defined as the primary package executable.
And, in the end, sometimes it's just the case that a product is not well-suited for installation using the Windows Update Agent. :-)