Have you looked inside Data::Table?

Have you considered the complexity of table formatting options?

As a starting point, consider only those options (currently available and not) for html output.

Now consider trying to provide transparent mapping of all those options so that they can be applied to Excel output. And now try adding all the formatting possibilities that can be applied to Excel cells, groups, tables and graphs, and retro fitting them back into the existing API such that they can transparently be applied to the HTML output. And also to CSV/TSV/Formatted ASCII.

And for bonus point, now try and do the same thing for all the formatting possibilities that can be applied to PDFs, and retro-fitting those options into the modules interface such that they can be applied (even if they do nothing!), to the HTML/Excel/CSV/TSV/Formatted ASCII.

And if you've got through those mental exercises, now consider adding support for RTF; and OpenOffice XML Document Format; and Doxygen; and Wiki; and ...

And then imagine trying to perform comprehensive testing of all of those.

And finally, imagine trying to write good user documentation for the behemoth that would result.

And all that complexity arises for what is ostensibly a very simple and easily defined input format.

Now imagine trying to do the same thing for generic data structures: Hashes and arrays seems trivial, until you start nesting them. How about handling circular references? What about dealing with Moose objects with all their possibilities for annotations. And derivation from any of: simple blessed hash-based classes; or blessed array-based classes; or blessed scalar-based classes; or any of a dozen different implementations of Inside-out object based classes?

The problem with what the OP is asking for--"given a data structure, provide a fully object-oriented method ... that renders the data structure to any number of common formats such as HTML, Markdown, Excel, etc."--is that it creates a bottleneck. Or perhaps 'tourniquet' is a better word here.

Many input formats: given a data structure; transmutating to many output formats: HTML, Markdown, Excel, etc. through a single API. There are 3 ways to go when you try to do things like that:

1. Lowest common denominator.

   Think POD.

   Supports rendition to every output format known to man.

   But only because it supports almost none of the facilities of any of them.

2. Fully comprehensive, extensible, virtualised API.

   Think XML.

   Sets out to be able to encode anything, originating in any format, into a format that any complaint reader can read. And it achieves it.

   But only because it moves all the meta-data into another document (and format) entirely: namely the DTD. And that format is so specific and so rigid, that no two are ever compatible. They basically dodged the problem but pushing it upstream, with the result that they achieved nothing.

3. Minimum working subset with generalised escapes.

   The best common example of this are filesystem APIs and the IOCTL calls.

   The common subset work--mostly; don't look too closely at the filesystems on CDs for example--most places, but at the expense of restricting innovation to an 'also ran' status.

   Ask yourself, why do most *nix systems still default to using Ext2 when there are much better one like Reifer available?

   Or why nobody makes use of the Streams facilities of NTFS?

   Once you define a minimal common subset of facilities, innovation is stifled to the point that it is extremely rare that that subset is ever extended. And that results in stagnation; or hookey proprietary extension mechanisms that never converge.

   Another good example of this is SQL. The movement in the standardised adoption of modern extensions to SQL is glacial.

   Such standards bring compatibility and interoperability; but they also bring uniformity and stagnation.