Recently I had someone contribute some coding changes for my project at work. I had made it clear that I wanted to know all of the things he had changed. He didn't seem willing to do that and for mostly political reasons, I didn't feel I could compel him to give a complete report. So I settled on a compromise: he'd give me a list of "interface" changes.
My idea behind that suggestion was that if he fixed a bug or reformatted some code, I really didn't care too much. But if he changed the way a part of the system operates, I'd like to know the general reasons why. A couple of weeks later, he checked in his code and reported the changes in the interface as he saw it and I started to test the code.
Not surprisingly, something broke. He's an outstanding programmer, but with a large system it isn't easy to make a large number of changes that work right out of the gate in every situation. After digging around for a few hours, I finally discovered the offending code. He had replaced an entire source file with a check-in comment something like, "Replaced with working version." His version changed the semantics of a function call in a way that broke a program in a non-obvious way.
Now, that sort of change is exactly the sort of thing I was fishing for when I asked about "interface" changes. His response was that since the function signature hadn't changed, the interface hadn't changed. And he's correct if we had been talking about syntax. But I don't care about the syntax interface. A compiler can tell me if that changed. I needed to know about semantic changes, which are much more difficult to discover.