I'd like to second Pragma's point, and add a few thoughts to that:

If your hypothetical module is going to be fundamentally different from Net::IRC -- meaning that people would use your module as a replacement rather than as an extension for Net::IRC -- maybe you'd want to think about identifying some feature that might stand out as unique to your version, and find some way to boil that down so it fits into the module name -- e.g. Net::LogIRC, if you worked hard on logging, or Net::UniIRC, if a main goal is to include support for typing/displaying unicode text. At worst, you could try "Net::YAIRC" (before someone else uses this name). But using "BUU" in any way would be a mistake, I think.

On the other hand, if your creative impulse can be channeled into building a module that extends Net::IRC, then your module name is easier to make up: Net::IRC::Extrafeature (whatever the primary "Extrafeature" may be). Doing it this way has some advantages for all concerned:

• The module parts that have to do with "infrastructure" (protocols, security, basic efficiency) will receive more effective peer review, and will tend to be maintained and upgraded more reliably, if they exist in a single "reference" module that everyone starts with (Net::IRC).
• The parts that you're adding to scratch your particular itch will be easier to write and maintain, because you don't have to worry about the infrastructure.
• Things will appear (and actually be) easier, more meaningful and more sensible for CPAN users. If I needed to write my own special IRC app, I'd prefer looking for a single "base" module and browsing through extensions for it, rather than having to compare a bunch of different base modules.