In general, this doesn't work by accident. In practice, whenever calling a function from a different DLL, normally a thunk is inserted (if it isn't marked dllimport), and when referencing a variable that might reside in a different DLL (and be autoimported), its address is read indirectly via a full 64 bit pointer.

When linking to a function "func" in another DLL, the import library normally provides two symbols, "func" which is a thunk which allows it to be called from anywhere, and "__imp_func" which is the IAT entry (containing a full 64 bit address). If the caller called it via a dllimport marked declaration, it's using "__imp_func", otherwise it uses "func" and ends up jumping via a thunk.

In some cases, when mingw-w64 wants to override importing certain functions (by providing a statically linked version of it instead), the functions are marked "DATA" in the def file (which is used for generating the import libraries). Then the thunk is left out and only the "__imp_func" symbol is left. If you hit a situation where you didn't end up linking the intended replacement function, then it's possible to hit this situation where you autoimport something that only works if it's loaded close enough. (In hindsight, it might have been even better to comment out those functions entirely from the import libraries.)

If you do hit this issue again (or if you remember exactly how to reproduce it), then plese do file a bug somewhere so we can look into it.

But in general, mingw-w64 linked binaries, even including ones using the autoimport facility and runtime pseudo relocations, should work even if they are loaded far apart from each other.