That's how Mason works after all, but using a single output buffer. Ok, that's shallow, I hope the fellow masonites will forgive me for this one ;-)

You should be able to quickly build yourself such a "multi-pass" system using your own conventions, following Mason's request cycle (briefly: gather output by running orderly each component in the inheritance chain)

For the sake of example, here's a possible approach for such an autohandler:

<%doc>
   # document everything (conventions, hacks etc) :P~
</%doc>
<%once>
   # load modules at this step only if you're not able to load them "a
+t startup"
   # (e.g. preloading them under a mod_perl enabled HTTPd)
   use My::App;
</%once>
<%init>
    # set up runtime/dynamic default configuration parameters
    $m->comp( '_conf', %ARGS );
    # ^ these should all be "notes" ($m->notes)

    # a <%shared> replacement (yeah, that's me,
    # I always avoided it for not doing what I meant) ;-/
    if ( $m->request_comp->method_exists('_init') ) {
        $m->request_comp->call_method('_init', %ARGS);
    }

    # fetch page content
    $m->notes( 'page_content' => $m->scomp( $m->fetch_next, %ARGS ) );
    # ^ remember that you have to *handle* the "exceptions"

    # <%cleanup> replacement
    if ( $m->request_comp->method_exists('_cleanup') ) {
        $m->request_comp->call_method( '_cleanup', %ARGS );
    }

    # render output
    return $m->comp( '_render', %ARGS );
</%init>
[download]