Hi Tim (and others),
thanks a lot for that implementation plan. It looks really well thought and mature! In any case, far better than current output system,
IMO 
I've been spending some time today reading it and thinking about the things I don't like in the plan, and also what could be missing or undefined.. and here it's my summary (directly pasted from my temp document and not reviewed too much, so I hope it will be understandable).
Note there isn't any "-1" to the plan as is, but some comments / ideas that IMO should be clarified and decided before any coding. Here they are (numbered for easier reference later):
E1 - "A key point to all this is backward compatibility. All of this will only affect pages that are coded for it. Older code will work as before, using deprecated functions." -> Seems that proposal will break BC is various parts, isn't it? Or is the key point 100% still valid and embraced? Else, which parts will be broken?
E2 - Why do we need $OUTPUT globally used everywhere? And potentially $PAGE too. Cannot everything be wrapped into raw functions, and hidden from the masses? Just an alternative to reuse current weblib functions providing transparent BC. Not sure about other renderers different from $OUTPUT (modules...).
E3 - In the example, I don't get the idea about how $OUTPUT and other renderers (modules...) will coexist. If module renderer has precedence over $OUTPUT... we can end with a nightmare of modules ignoring $OUTPUT and overriding it, making themes (and core) renderers unable to decide appearance (and that's a nono, IMO). It seems that, while theme renderers can override OUTPUT_renderer completely, other renderers, like modules... shouldn't be able to override it at all. Two different type of renderers needed, I guess.
E4 - Blocks positioning... 100% free? Each page can create "slots" in any place? Any idea about how to move blocks around? And how to identify those slots properly?
E5 - My +1 to use verbal function names: print_xxx() get_xxx(), render_xxx() or whatever, instead of simple xxx() ones. Seems a bit reiterative but needed IF those objects (PAGE, OUTPUT) have methods for non-rendering functionalities.
E6 - My +1 to have the print_ and get_ duality applied everywhere. 100% Although I'm not sure if best implementation is duality of functions or extra param... or some sort of $OUTPUT->enable|disable_capture()
to instruct functions to return instead of print... different alternatives to achieve the same thing each one with its own pros|cons. Personally I prefer always to have getters and then output them via echo, as ML stated above or, the lesser evil, 100% separated functions.
E7 - Some way to improve printing in general, in a centralised way? Perhaps related with all this PAGE and OUTPUT stuff? Being able to disable output of some parts (blocks...) completely, not only by hiding them with CSS? A general "print mode" link available for all pages, calling same
URL (same than original) + "&printmode=1", but causing PAGE/OUTPUT to know they are in print mode.
E8 - How will some pages, sometimes displayed in popup, sometimes in normal page... skip printing some parts like headers, breadcrumbs and so on (message pages, glossary filter.... and some more here and there). Any chance to get $PAGE->inpopup or so filled in a standard way, similar to prev point (aka + "&inpopup=1") ?
E9 - Any chance to get those renderers not printing only XHTML but other output formats? Crazy idea I know, bur perhaps could be considered for future expansion of the whole thing and could be supported in a transparent way since day 0 (defaulting to XHTML).
Hope this helps... ciao
