I guess it's just a difference in philosophy and attitude. On software projects I code, I leave backwards compatibility in if possible. Most of the time its very simple and never a kludge.
I think our difference is not in philosophy, but in scale. I'm thinking 10 year maintenance timeframes, not the immediate release.
Again, this philosophy of not supporting backwards compat where it is easy to do will just hurt in the long run, like it is hurting php, apache, perl, and other projects.
Sidenote. http://news.netcraft.com/archives/web_server_survey.html
<sarcasm> With over 68% market share, and increasing. Clearly Apache is hurting badly. </sarcasm>
I agree that yes, breaking change is sub-optimal.
However, you also need to keep in perspective the costs of backward compatibility.
Once you go that route, you must ALWAYS go that route, for every change, or your efforts are more-or-less pointless. 90% backward compatibility isn't really much better than 0%. If the user has to edit a config file to upgrade, it's a pain.
Also, once you decide to support an old option, you must support it for the life of your project and never break it, otherwise all you've done is delay the problem the user will eventually face, and maybe even make it worse as they may become deeper entrenched in outdated syntax.
By preserving backward compatibility with subject_tag, you save them from having to fix one issue. What about the myriad of others? Should SA 3.0.4 support all old syntax from 1.0 onward?
