Thanks, this is clear now. `merge_scalar` won't quite do everything we need here, though, since (a) it appears it's possible for the post-processor to produce a new output file, which needs to be chained into the next post-processor, and (b) the ordering is sensitive: in the ioslides/html_document case, it's necessary to invoke the html_document post-processor *last*, since the HTML-preserved chunks are not visible until ioslides is done with its own post-processing step. I have this fixed here: https://github.com/rstudio/rmarkdown/commit/cb2537ae286cb9128f1a931183bd60cce5099867

It feels a little backwards to run the most specific post-processor first, but you could also think of this as the overlay post-processors producing a common format understandable to the base post-processor (like a derived class doing work and then invoking a method on the base class with partially digested data).