This is probably not what you're looking for, because it sounds like the module is developed by your organization so you could eventually directly contribute to its final shape, and it's probably not what you should be doing, because there are usually better ways to change how you interact with a module, but:

In an old version of Path::Class, Path::Class::Dir had no "basename" method defined, while Path::Class::File did (and ::File didn't provide dir_list, etc). If you got passed some file object, there were multiple and mutually-exclusive code paths you could follow to get the file name. So I just added this to my module:

sub Path::Class::Dir::basename { $_[0]->dir_list(-1) }

This added that function, by its fully-qualified name, as "basename" into the "Path::Class::Dir" package, from within some other package! You could also do this with:

{
    package Path::Class::Dir;
    sub basename { $_[0]->dir_list(-1) }
}
[download]

Which is like opening the package, defining subs or creating variable or importing symbols, and then closing it.

You can also redefine existing subs in the same way (and surpress or ignore the resulting warning messages). But be very careful with this. Changing how an existing module works internally, especially when you redefine methods, without calling the originals, or change its internal data structures, can result in very confusing errors. This is especially prone to happen if the module is used in multiple places or ways in your program, eg indirectly by another module you're using.