What would make it the most easy for me (and many others) to use is to allow CSS + HTML to be a feed interface.

I second this idea. As web pages have been getting more and more styled, there's been plenty of thinking and draft specs about how to use XHTML and CSS to specify paged media layouts. E.g. XHTML-print and CSS3-page. Rather than reinventing a way of describing paged media and then coding up how to render it (look, it's a print-driver written in Perl!), I'd rather see an implementation that conforms to even some subset of these emerging standards.

What this would do from an interface perspective is really decouple the problem. The PDF generator would need to generate XHTML (using one of several existing back-ends like HTML::Template or TT), be given some CSS (either a trivial default, or something hand-written by the report designer or even something generated from yet another template engine) and just render that following the W3 spec. That would even solve the documentation problem since there's a pre-existing spec for designers to read.

For the use case mentioned -- giving a printable report that resembles an existing web page -- the existing templates and CSS would serve as a base. Just throwing that at PDF::Template::Future should produce something not far off from just hitting "print" in the browser, and then the addition of the page-specific stuff should start tweaking it to turn off web-only features and manage the pagination more rationally. That seems much less of a headache than translating it into a substantially different XML format or other mini-language to regenerate a similar-looking report.