RFC: PSR-15 / Replace HTTP Component completely, with Flow 7.0

That’s a good idea, and probably the collection in the other thread we have will be a good start for such a documentation.

I also assume that there won’t be any migration script possible.

Yep, very unlikely we can build a migration script that translates those things automatically unfortunately (anyone willing to attempt that is highly welcome :)) - but once you know what from the components concept translates to what in the middlewares, it’s relatively straightforward (e.g. $componentContext->replaceHttpResponse($response); + $componentContext->setParameter(ComponentChain::class, 'cancel', true); = return $response;).
The hardest change is likely finding the “correct” position in the new middleware chain. Since the separation of the three chains (pre/process/post) is gone, you might need to put your “post” component somewhere at the start of the middleware chain to make it work as expected.

Again I compare to the PSR-7 change. We had many people in Slack quite lost on how to replace their code. I myself struggled in some places.

I totally understand that. And we could maybe have done better with that change, if we would have had more time and maybe a few more people help with playing around with the change early to collect the migration/maintenance issues that needed to be solved. Effectively it was mostly a two-man effort and we needed to push through this change to get it done at all, by the sheer amount of code that needed to change and was hard to review.
See also Flow PSR-7 change in master, we need your help!

So let’s learn from that. We have only one and a half month till the release (still more than when we merged PSR-7). I suggest we try to merge the core components migration to middlewares ASAP (see e.g. FEATURE: Move TrustedProxiesComponent to Middleware by sorenmalling · Pull Request #2153 · neos/flow-development-collection · GitHub and FEATURE: Move Session*Component to Middleware by sorenmalling · Pull Request #2154 · neos/flow-development-collection · GitHub), then prepare a good migration documentation with examples and try to get feedback on how hard the actual migration is in real projects (maybe we need to document, how a project can test against dev-master in a sane way?). If we see it is straightforward enough, fine, otherwise we try to push a b/c layer in - but as stated above, I still don’t see a “perfect” solution for that yet.

It would also be interesting if a package can be made compatible with Flow 6+7 at the same time.

Absolutely! But we need feedback from package maintainers to assert what works and where this doesn’t work.