First, a reply about the whole 'plugins' thing. Personally i dont see it at all neccersary, there is very little you can do with a 'plugin' (modification to mirc.exe itself), that you can not do with a dll (or a few working together).
In your specific example of the blowfish patch (note that its always been buggy from the day it was started, and as such i refuse to use it, thats the nature of third party modifications to the mirc executable), the same result can be achieve with the use of some dlls and scripting.. there is a nifty little dll called io.dll that can catch incoming/outgoing communication between mirc and an ircd and halt/manipulate it.
This makes it relatively easy to write a script that uses this dll to detect incoming encrypted messages (or catch and encrypt outgoing messages) by replacing the data in the caught message with data that has been altered using ANY encryption dll such as fish.dll
Dispite this (which is how i have done it for the time being) there have been a few suggestions in the past for generic text encryption support built into mirc, one by myself, which i personally think would be great but also realise thats its the kind of feature that the general mirc userbase isnt particularly interested.
Native text encryption (eg blowfish)I believe there have been others, but i only did a quick search of my own suggestions.
Anyway, i am all for generic text encryption support even if it was just designed to call specific functions in whichever dll its set to use (dll would have to be created with mirc in mind and use appropriate function names), and a good key exchange method (weather it use DH like the blowfish patch does or any other/better form). But as far as 'plugin' support in the way that it seems your suggestions i dont see the point.
As a side note, and i believe i have mentioned this before also, a dll management dialog could be very useful. It could allow you to add feature enchancing dll's to an autoload list (when mirc starts) that could add functions/identifiers/features/etc to mirc without needing to script calls to the dlls. (eg a dll could autoload, and upon autoload send a command to add a button to the toolbar, and interpret the click of the button to launch a dll coded dialog, without any need to use mirc scripting)
