While I suspect this particular presentation of the issue might be fixed by a change to XMG, perhaps the method it uses to load comments (not really a reason to be using deferred loading on a default-open tab, unless comments are updated live)...
This issue should actually extend to anywhere that XenForo (or an add-on) loads an editor asynchronously, commonly inline post editing, and this is a core issue that can only be resolved by either changing VaultWiki or XenForo (although changing VaultWiki would be a "workaround" and not a fix for the underlying issue). VaultWiki expects script tags to execute in the order it provides, and XenForo executes script tags in whatever order it feels like.
As mentioned above, there is a workaround that will be employed in the next release: don't load VaultWiki editor stuffs if XenForo is doing something asynchronous. This might lead to lost functionality, but currently is the only way to go about it due to non-existent Javascript events at the appropriate position.
A true fix would be for XenForo to update its asynchronous loader to be queue-based, rather than execute-when-loaded. This can still be achieved asynchronously, without any real added latency:
1. Asynchronously load included scripts to memory.
2. As each script is loaded, add the result to a queue in the original order.
3. Execute the ordered queue.
As it is now, there is no queue and no order, which can cause Javascript conflicts (X-dependency is not loaded yet, etc, even though it was first in the chain).