Okay. A dictionary definition of a regression is
Originally Posted by Sxooter
A change from a more developed to less developed state
As this applies to software engineering, it doesn't quite apply since within software, you don't have a monotonic improvement as a system is developed and maintained.
This coupled with a general lack of test and orthogonal constraints (performance/integrity, etc), you can't just make a simple if it's worse, it's a regression.
As a result of this ambiguity, any change that is unexpected will usually foretell a lack of planning/awareness of impact. The KVM guest faster than host SQLITE test was a great example of this. The performance increase (argued by some as not a regression) showed a decrease in integrity (obviously a regression for some) showed that there was a change that was incomplete (the actual regression).
So rather than always get into an argument - it's the question of if the change is expected. ie: someone has a git checkin that explitly says "trade off performance for data integrity. Usually, however, the likelihood of a checkin like this going in without a week long flamewar due *only* to the fact there is a tradeoff explicitly highlighted in the checkin.
Ergo, there are *LOTS* of regressions, and regressions can be great or devastating depending on your point of view.