I really like the idea of being able to specify which pages are slipstreamed. We don't need to ensure the whole of any Composr site can work with it, we can do it on a page-by-page basis, optimising the pages that are hit most on any particular site.

This is implemented, except we're not iteratively streaming MIDDLE as it is generated. This would give very little performance gain because MIDDLE in total isn't usually that time-consuming (at this point we have already off-loaded some complexity into pre_run, and pre-sent a lot of output to keep the bandwidth busy). There is also a major problem, if an error occurred mid-way through generating MIDDLE, we could not recover to display a clean error message.
That said, we can still do this on a module-by-module basis, if we so choose. We just do this via not attaching Tempcode objects, but instead echoing them out immediately. This can be multi-layered also. It's not more work than having an API to do it, and actually cleaner.

In terms of what is implemented...
Almost all modules have been made to support output streaming. Comcode pages have it implemented. Minimodules do not, as they are not sophisticated enough to pre-declare things like screen titles, but are likely to use them.

All-in-all, this is a really nice improvement. We don't yet have the self-learning cache implemented, so things look a bit funky when CSS includes aren't loaded initially (the browser has to re-render the page, so flickers). When that is done, it will be even better. There is no overall performance negative on the streaming, and strong positives (psychological, seeing output start sooner; bandwidth kept busy due to lower latency; connection kept prioritised through routers due to faster response).