The main linker (there are also secondary linkers, but they are not involved here) is responsible for creating * .js or * .html files that host the compiled JS-code, and, of course, how to upload / download them to the browser.
Once you know this, it becomes obvious that they must explicitly support code separation.
For example, the xs (cross-site) linker transfers the entire script to an anonymous function, so it doesn’t “pollute the global area” (the method is also known as the module template). Then, it cannot dynamically paste some other script into the page, which will have access to its internal elements. The sso liner (single-script) has the same limitations.
The std (iframe) linker loads your application into a dynamically created iframe that serves as a sandbox: the global iframe is not the global area of the main page. Then it can dynamically inject the script inside the iframe, which will have access to everything that already exists (global iframe scope).
But in fact, you don’t have to choose which linker your application should use: stick with xsiframe (which you must activate explicitly, however, for now it is). It combines the interstitial friendliness of the xs linker with the std linker iframe sandbox.
You can expect all other linkers (except perhaps sso ) to become obsolete in future releases of GWT and eventually be removed altogether; and the std linker, which will be replaced by the xsiframe linker as the default linker.