Well, my opinion is that the quest to find a "simple" process is leading to reinventing the wheel with a fork and a spoon rather than a hammer and chisel. This new issue is not a new problem and would have been addressed with the appropriate process of creating pull requests against the release branch, or even merging to the release branch instead of master. But there seems to be some confusion about this (now that it has come up as a replacement for writing notes back and forth).
In your last email you took issue of adding a second review step, when the first doesn't get any attention. This is wrong, dead wrong. There should not be two reviews, there should only ever be one single pull request and that request should get the review.
Yes, this approach does require involvement of the patch contributors, but that is already true. The contributor is already tackling regressions for the new release, so they're already aware of where this fix needs to go. It just requires them to check out the release branch on the three repos before starting.
Even if the developers don't wish to push the request against release, they can still leave a comment on the Pull request (against master) stating this should go into release. At this point the pull request is NOT merged into master, instead it is merged into the release branch. This approach has the negative that the fix may not be complete or have merge conflicts due to dependency on previous changes (this would be where a comment should be left and request that the issues be addressed).