Not side by side, but one after the other is perfectly fine and not breaking anything. That is also the current status as of Flow 6.3, where the middleware chain “wraps” our old component chain. So you can already write middlewares, configure them and play around with them, as long as they don’t need to run between components.
See above, even 6.3 works already to experiment 
In master we will only remove the existing components, so you can no longer order your own components relative to existing flow components (once we are through) and that is in fact the breaking part of the change.
We could indeed keep the “ComponentChainMiddleware” that runs as the innermost middleware, so existing components could in some way still function. But that begs the question what the reason would be, when components can no longer “interact” with (wrap/interrupt) the Frameworks own http kernel layers.
I’m not sure if @bwaidelich had a chance to talk / write to Alex already?
I did have a talk with Bastian a couple weeks ago regarding the middleware change for 7.0 and he too was on the side of keeping b/c as much as possible. Since then I just found this harder to achieve than anticipated. See also my post in the other thread that @sorenmalling already mentioned RFC: PSR-15 / Replace HTTP Component completely, with Flow 7.0
I would love to have existing components simply work as a middleware without having to touch code, but right now I can’t seem to find a solution that works for all cases.
But nothing is decided yet. The current open issue for the final switch to middlewares is Convert existing HTTP Components to PSR-15 middleware · Issue #2019 · neos/flow-development-collection · GitHub