In such cases (extending a framework simply by adding classes and having all changes local to these classes), I use a central registry (either the Windows registry, a singleton object in my program or an external text file). That registry consists of two fields per entry, name and service. The name field is unique to allow identification (this could be the filename of your plug-in), the service field contains the name of the service this module provides (in other contexts, this is called an interface).

In order to make installation as painless as possible (simply copy a file), you could blindly require() all .pm files in the plug-in directory, and evaluate the &getServiceName() function that every plug-in must export. This also makes deinstallation painless, but it makes each program startup slow, as every plug-in must be loaded, even if it's not used at all.

This scheme dosen't relieve you of specifying what happens when two plug-ins supply the same service, but the program will only either one of these two plug-ins - here some UI/configuration would be in order.