Does the documentation needs to be part of the core git repository? Remember the time we wrote documentation separately in the wiki? That was not ideal, but a similar approach using git could probably get rid of most of the problems you are explaining above.
A dedicated separated git repo for these changelogs (similar to https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-CoreApi). The workflow of creating new features, deprecating or breaking stuff for the developer could include creating a review request for the documentation in that repo. This repo could be cleaned up whenever it fits, and the doc team could render a documentation from that repo just like any other core documentation (TCA, CoreApi, etc).
The core repo would not have any of these directories, there is no need to do anything when releasing (rename directories, delete stuff, move etc), there is no need to backport rest files, etc. Improving these ChangeLog could be part of the “documentation” effort and not core code review process. docs.typo3.org rendering would be easier.
The extension scanner would need to have access to this repository for it’s work, which means for example provide the content as a “zip” which the tool downloads on demand.
Going one step further, the information for the extension scanner (Configuration/ExtensionScanner) could also be put on that separate repository, so that the tool could scan for problems on TYPO3 core versions that are not the current ones (i.e. when planning an upgrade) and we can also update these instructions independently from the core itself. So I have a 8.x installation and want to upgrade to 10.x, the tool fetches the “changelist for 9.x and 10.x” (rest + php matchers) and apply these rules.
