First, consider that WINE is by definition aiming at a moving target: it's trying to provide a windows compatibility layer that allows Windows applications to run on Linux. Hell, Windows isn't even compatible with itself! Second, consider that the Windows API itself has many thousands of undocumented or poorly documented internal interactions. Programs can quite frequently end up being dependent on those interactions without realizing it. (BTW, in all fairness I should say the above criticisms could also be leveled at most any flavor of Linux) Third, consider the sheer NUMBER of applications that run on WINE, and the effort that would be required to undertake a regression test every time an update comes out. In short, the nature of the beast is that Windows is constantly changing its behavior, and doing so in undocumented or poorly documented ways. Applications can end up being dependent on hidden Windows behavior without realizing it. Because of this, seemingly innocuous changes in WINE's code can result in significant breakage, through no particular fault of the WINE devs.
I honestly don't know... The Wine community is so HUGE between Wine users, Crossover users and PlayOnLinux users, we have already determined many games that work well with specific versions of wine. Then people like me come along and try specific games with newer versions of wine and it still works. This is the heart of the reason why I want to post test submissions on WineHQ... So people and developers know these games work on the newer versions of Wine. By the way, my submission was accepted after I changed tested version of Wine to 1.6-r4