As long as the module boundaries don’t change, one can change the functionality of the module freely, without concern for breaking the wider system; i.e. the impact of any local change is prevented from leaking into the wider system.When the implementation of a module is changed without changing its interface, the only certainty that you have is that it can be invoked just like its previous implementation, without recompilation. But above that, nothing is certain. My point is that a module is invoked for a reason: to perform some useful work. The interface of a module says something about the structure of the information that it needs to do its work, but very little about the work that it will do, and very little about how the information provided to it will be used to influence the work done.
Take for example a module that offers a service to transfer money from a checking account to a saving acount. Its interface will probably specify the account numbers of the accounts involved and the amount of money and the currency as required parameters. What if a new implementation, instead of faithfully depositing the exact same amount to the saving account that it withdraws from the checking account, now does nothing at all? Or worse, deposits just a little less that the amount withdrawn? Or performs the transfer of money in the reverse direction? Does this not break the 'wider system'? Of course it does!
Coupling may be more subtle than just whether or not it breaks compilation. Testing the new configuration is still needed, automated (preferably) or manual. And testing is usually still an order of magnitude more expensive than compilation.
