I dread the day someone figures out a way to weaponize this in practical fashion. I'd be astounded to learn that not-very-practical attacks don't already exist.
You can't really weaponize this, because if you're controlling the source code to a program written in C or C++ on a victim's computer, you've basically already won.
What I'd expect is that some loads / stores get optimized out across modules, causing bugs in multithreaded programs that were living the high life in x86 memory model land. Of course, these programs probably already have other bugs.
To be honest, I'm not so sure about that. Two attack surfaces I can think of off the top of my head where that could be leveraged are dynamic plugin loading, a-la old school ActiveX, and LD_LIBRARY_PATH attacks on ld.so based platforms.
One might say that both of these vectors are obsolete, but anytime you have a dynamic coding situation, that is one more term which is added to the equation of how one can interact with a system, regardless of its legitimacy.
Or perhaps another example involving attacks which use many vectors, a dual action bytecode verifier & x86 shellcode attack:
http://www.securityfocus.com/blogs/746
If you can convince any piece of code to do the unintended, that can be a constructive attack vector. Sure, we can harken back to the old days when code only did simple parsing and stayed away from data parsed in multiple contexts. I doubt that will be a sellable market proposition in the age of the Internet of Advertising, however!
I think you are confused between what linking and DLL loading are. They are different things. Linking is a step done during program development on object code by a compiler toolchain program to produce an executable. DLL loading is a step done by the OS on a user's machine at runtime to load an executable. Most non-developer Windows user machines will not even have a linker installed on the system.
