This can be a hassle, if we change a lot of things in the HTTP Component afterwards - but since we deprecated them (the HTTP Component context etc), what support and maintanence do you expect to have for a package versioned 1.0 that uses HTTP components, if 2.0 and beyond is a middleware implementation?
Middleware has been mentioned since 2016, Alexander did the first work about one year ago (from reading issues) . We could have decided to push the topic harder and have had it in for the 6.3 LTS release - but I don’t think any time would have been better than other 
We didn’t get it in for 6.3 LTS - so kept the LTS stable with concept known, for a longer support release.
Instead we are pushing this along with many other topic for the major 7.0 release.
To work with a framework following the PSR-* standards - “easier” adoption, due to usage of documented concept, describes in numerous of blog post, written by none-Flow users, but still they can use the concept and values.
Mentioned here RFC: PSR-15 / Replace HTTP Component completely, with Flow 7.0 - #8 by aberl - Alexander did some concept for that, but he mentiones the drawbacks, so it’s out there in the open.
The other way around - it’s about others middleware being usable by Flow. Which then (secondary?) leads to, our middlewares being usable by others
