The case for the /usr merge

True enough... But, if it's just some obscure rarely used feature, I'd think it makes sense anyway... Even if you don't want to indirect all API calls through dlsym() and such, what you could do is separate out all the code that interacts with that library into a sort of plug-in library of its own, needing just one simple call into that lib from the main app to do everything... The separate lib can still directly call all functions from the system library with no confusing indirection, and even be linked against it if you want... (Or, the main app can just dlopen(RTLD_GLOBAL) it prior to dlopen()'ing this separate lib...)

This is in part because the library wasn't designed for this use case in the first place.*

However, why should the library be directly dlopen'd? Why not put a plugin architecture into wpa_supplicant itself, with the plugin linking against the library normally, and with only a very narrow and plugin-friendly interface being shared across that dlopen boundary? This even makes it trivial to have the package manager intelligently support the package dependencies by putting the plugin in its own package; users who need the feature install the plugin and get all dependencies pulled in, and users who don't will not need those. There's then a case to be made that the network configuration tools in Anaconda and the desktop tools need to be made aware of feature package dependencies to pull these things in automatically, but that's a polish thing (not FOSS's strength, but not out of the realm of possibility by any stretch).

[*] There's an argument to be made -- especially in the FOSS world where the source is available and modifiable by anyone and everyone -- that libraries should offer the kinds of interfaces their clients prefer, rather than client applications making "not our fault" claims when library interfaces don't allow features users want (like moving dependencies from compile-time to run-time).