Your screenshot shows an active dialog that looks like it's using MDX-- meaning the dll is still "in use".
mIRC has unloaded the dll, but it is still resident in memory. This can happen for many reasons, including threaded code, an improper UnloadDll function, etc. This would be MDX's fault, not mIRC's. DLL developers have to be much more careful about how they interact with mIRC's API. mIRC cannot *force* a DLL to unload, it can only trust that the dll properly implements UnloadDll and cleans up as it should. It seems like MDX is returning the wrong value during unload, and/or not properly cleaning up. Since it's unmaintained, I don't think that's going to get fixed.
To elaborate, when you /dll -u a dll, mIRC calls UnloadDll() on the dll itself (see /help DLL Support). mIRC expects the function to do proper cleanup, ie. remove any threads, release resources... it then immediately unregisters the dll as being loaded. It can't verify that the dll is no longer running any extra threads and has completely removed itself from memory-- it has to assume that it did a proper cleanup. mIRC is reporting what it should, but MDX.dll is not properly unloading.
I bet if you close that dialog, you might be able to delete the dll-- assuming it properly shuts down at that point.
