If you're really that much smarter than the module designer

I never said I was smarter than anyone. Everyone makes mistakes. The mistakes I run into are usually simple mistakes not complex mistakes, hence "stupid mistakes". The most common being "nobody would ever need/want to do that", often probably the possibility was not even considered. This doesn't make the module designer stupid nor does it make me smarter. If I'd meant that I was smarter, then I wouldn't have mentioned my own stupid mistakes. But take offense if it helps you get through your day. (:

know so much about the internals of his design that you can reliably call functions that manage the system's internal state without any fear of ill side effects

Sorry, but most Perl modules aren't rocket surgery. I've got the source code. If I can't discern the inner workings of the parts of the module that I'm making use of fairly easily by reading the source code, then I'm likely to reconsider my decision to use the module. I rarely even have to grok the entire module contents. Even within a module, reasonable design principles mean that there are modular parts that are fairly isolated from each other. It is usually pretty easy to verify that doing X doesn't break things by just looking at every place that X touches. If traversing that tree of effects isn't a short trip, then it isn't a quick work-around and I'm not likely to use it.

why not just change the module to be what you want it to be?

Getting my work done with a quick work-around of some misfeature of a module can be very expeditious. Fixing the module's misfeature is usually quite a bit more complex. Often worse still, it creates a dependency problem. Making the fix of high enough quality that it is appropriate to put on CPAN is usually significantly more complex still. Then there is getting permission to distribute the fix.

I discovered that a script was sucking up all of the available CPU and figured out that the problem was Term::ReadKey. I looked at the source and found that it quietly becomes a busy-loop if a certain compile-time test failed and, sure enough, that test fails on FreeBSD. I commented out that test, rebuilt, and the module works perfectly w/o being a CPU hog. Unfortunately, this was a diversion in a spare-time volunteer project and I regret that I didn't find the time to report the problem. Later, when the module author heard of the problem, they seemed a bit upset that I didn't send them the fix. I didn't have a fix. I had a work-around. Commenting out one test is trivial. Fixing the test so that it now works on the version of FreeBSD that I was using and doesn't work less well than the previous test on all prior releases of FreeBSD and all other operating systems that Perl runs on, is something that was way beyond my knowledge. I don't even have the knowledge that went into the selection of that test. So I'm not at all qualified (or "smart enough") to suggest a fix for it.

If the work pans out and results in something that I'm going to need to do again or to release to others, then I need to clean things up and the quick work-around is no longer enough. Then I'd fix the module or look for an alternative.