This has happened to me several times -- upgrading to a new Rails release breaks my app because things have been removed from Rails. Granted, a simple plugin install usually fixes said issue, but it's weird to me anyway.
I would expect code to be improved and proven in a plugin, then ultimately integrated into the framework. Rails tends to do the opposite for some reason.
Maybe someone smart can explain it to me.
It also violated a core Rails statute of never dictating look'n'feel of the end application. The error_messages_for included both fixed copywriting, HTML structure, and relied on CSS. Ugh, bad shit.
We've replaced the output in scaffold with the unfolded iteration. As you'll see, it's incredibly simple.
I think since the beginning of Rails' inception, this feature has been included in scaffolding, shown in docs, etc. I would expect most Rails apps to use that particular feature.
And that's just one example.
Not everybody builds Rails apps the same way. I think that this flexibility is one of the framework's strengths.
Ruby code is simple enough that the process from good idea to implementation is small. That makes road maps meaningless because you can only map what you know. And if what you know can be turned into code instantly, why not do the code directly instead of writing down that you're going to do the code in the future?
We do deprecate everything gracefully, though, and there'll always be a good alternative to go to. For error_messages_for, all you need to do is add 1 line to your Gemfile and you're all good. Not exactly shattering.
If you find other, specific places where backwards compatibility is broken without proper deprecation or with a suitable plugin to carry you over, please report. We consider that a bug.