In addition to what Urwumpe said, I can see version problems coming up. If you have addon A using a library C, which also addon B is using, but both use a different version of it, chances are that the user encounters various type/interface mismatches depending on what addons he has installed. The chance gets greater the more addons are installed. If somebody comes up with something like CVEL as implicitly linkable DLL, users would be in for a great run-time pain if everybody just dumps their CVEL.dll into its own folder.
Of course this problem is also there in the common folder architecture we have right now, but it is immediately obvious on install due to overwritten files.
AFAIK, C++ does not have a strong naming system like .NET . A mandatory file naming scheme could compensate a little for that, although it would be cumbersome and still error-prone. Another option is using explicit linking (or late-binding) instead of implicit linking, but this often needs an architecture redesign of the addon/library interface.
The pull request adds support for this behavior. If a directory exists with the same name as a plugin, it is added to the PATH and searched by LoadLibrary().
If your addon already uses explicit linking via LoadLibrary calls, why not give the absolute path (to the subdir) instead of just the module name? Is it due to subsequent implicit linking in the libs you are using? In this case you could use
LoadLibraryEx with absolute path and LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR .