> the changes.txt log should be in the INCOMPATIBLE CHANGES section rather than IMPROVEMENTS
I don't think a deprecation is an incompatibility. It doesn't break user code.
Our pattern is to try to deprecate things in one release, then remove them in a subsequent release. Then user code can run unchanged with each new release, so that the release may be easily evaluated. And, if after upgrading, you remove all uses of deprecated code, then you'll be able to upgrade to the next release. The question is, where in that cycle is the incompatible change?
Arguably, for applications that play by the rules (removing use of deprecated features in the current release before upgrading to the next release) there are no incompatible changes in this cycle. Even if we do want to label such deprecation/removal cycles as incompatible changes, we should probably choose one event or the other, deprecation or removal, as the incompatible step. I'd probably opt for removal, not deprecation. Thoughts?