You are right: signatures do not encompass behavior. Some other examples I have observed: What if the implementation of some (signature-identical) function cha

You are right: signatures do not encompass behavior. Some other examples I have observed: What if the implementation of some (signature-identical) function changed its performance characteristics dramatically, such that it was no longer valid for use in certain scenarios (i.e. something that previously checked the filesystem now makes a costly query against a remote database)? What if a function that was previously thread-safe changed, and became non-thread-safe? What about changes in space (memory) consumed by a function? These aren't rare classes of behavior change, and they certainly aren't rare pathologies for bugs. And, at least in Go, there's no easy way to encode them in the signatures and/or memory layout of your package in such a way that two non-identical versions can be tested for compatibility automatically. These aren't edge cases.