Unfortunately, the code snippet in your example will always result in this manner, with the race condition if it's done outside of Launch's rule order controls (for example, if you are doing this within custom code action blocks).
In your example, " window._satellite.track('commonsPageLoad'); " gets fully executed, but it is only a direct call that then 'triggers' another, completely separate process. The separate process does not have any relationship or callback to this. The direct call gets a response that it was a valid call, but doesn't wait for further execution to complete before moving onward.
There's a few ways to provide timing control and callbacks/promises, but the easiest way to do it is to make the calls from somewhere that will still be within Launch's timing control. Adobe Launch likes to execute rules sequentially, meaning if you have pre-requisites you can create them as earlier rules on the same trigger, or direct-call them before you get to the "actions" area of the current rule. Order of operations and Launch's timing control is a fairly complex concept, because of the staging of Analytics Extension Actions, but if you add debugging outputs to the various stages, it can help tremendously.
If Rule 1 has a condition-block with the direct call to trigger Rule 2, then Launch must evaluate the conditions of Rule 2 before it can move on with the next set of conditions or actions for Rule 1, meaning executing actions of Rule 2 before performing actions of Rule 1 since the conditions of 2 were completed first (with more crazy-nuances depending on the type of action blocks you have for these rules).
If Rule 1 has an action-block with the direct call to trigger Rule 2, then Launch simply executes the direct call, and moves on to the next action immediately. This means Rule 2 ends up executing whenever it can get around to it.