I see your point which is semantically valid. But there is something more to it. Consider it from the other direction: You can introduce a bug by making some modification to the code. Then you add another modification which produces the same erroneous behavior. Either one alone would be enough to cause the problem. And two of them together does not cause any more problems than each of them alone.

But now to "fix" the problem you have to undo both of your modifications. You have 2 bugs and you have to "fix" them both. "Fix a bug" as in "Kill a bug".

So "Fix a bug" can mean "remove a cause of the problem". Or it can mean "remove the problem".

Your answer reminds me of “gettiers” (http://jsomers.net/blog/gettiers).

Obviously it'll be a bit contrived for this example, but... Suppose the logic that checked whether the input was a number used the hardcoded string "CARTER" rather than the value from the input. And, totally independent from that, your error display code just displayed the hard coded "example" value '"CARTER" is not a number' regardless of whether the state was correct or not.

In this case, I would say you have two bugs. First, that you aren't evaluating the actual input data and second, that your error checking code is not running correctly but just defaulting to the same value all the time. Bugs are distinct problems with your code, not problems that the user encounters and you have two distinct problems with your code.

That is a very project managery view of things. And in a simple system you might be right. In a complex system multiple different things can cause same looking problems.

Let's say you are not working on a "number box" (whatever that is) but a drone airplane. Your costumer reports that the drone become unresponsive and crashed.

You investigate and find that there is a buffer overflow which sometimes gets triggered in the navigation system which trashed the memory and lead to the loss of the drone. You develop a patch, and additional testing etc etc and you deploy the fix.

A year later a drone crashes again. You do the investigation and this time you find in the engine control there is an edge case which causes it to shut down the engine under rare circumstances.

Was the first fix not a fix? If I correctly interpret you it wasn't because the "drone becoming unresponsive and crashing" problem still persist. Obviously that is not a useful way to look at the work if you actually have to develop the fixes.

Obviously there was two different problems, and they both need fixing separately (often by different teams). Just because you are not aware of the second bug when you deploy the first fix doesn't make the first fix not a fix.

Of course you might say in this hypothetical the "problem was not the same" but you only know that after you have investigated. If there are no reasons to suspect the second bug, and during the testing of the first fix things appear to be working you have no way of knowing that.

> if you do a fix and the problem still exists then how is that a fix?

The problem was fixed after the two bugs were fixed:

  fix(problem) <= fix(bug1) & fix(bug2)

Have you ever had allergies and a cold at the same time?

https://en.wikipedia.org/wiki/Hickam%27s_dictum "A patient can have as many diseases as they damn well please."