It does seem that a bit more effort up front in design might go a long way. A couple of things I would suggest that have proven helpful to me:

The rule: NEVER CHANGE THE INTERFACE

Just accept it and design accordingly. I have never seen a case where the the interface needs to be changed; particularily in a way that breaks existing code.

Couple of things to try:

1. Have functions that take hash references. We use this all the time for cases that we know we will want to extend things later, or we want to make use of multiple overloaded parameters. As long as you ensure the default is equal to the old behavior, you even get to reuse all your old test sets.

$Stock->GetPrice( \{DATE => 'YESTERDAY', TICK => 'MSFT'}) || $Stock->H
+andleError();
[download]

2. Use inheritence. Create a new module, inherit the stuff you need, overwrite the functions that need to change. The API of the old module is unaffected, *and* you have implemented the new functionality to meet your current needs. This also works if you have to deal with someone else's design, which is a plus.

3. Limit the functionality; have a single function/method do a single thing. The cases where API's really need to *change* (rather than say, be extended by adding new functions) often are associated with having functions that do too many different things. Consider having more methods/functions with fewer parameters, rather than fewer methods with more parameters. Adding new methods does not break existsing code/test cases; adding new parameters does.