Ultimate objectives of the Perl 6 documentation tooling

It's difficult to redesign a documentation system (see also this issue if it's not clear to us what are our targets, and what we want to achieve; ultimately, where we want to arrive when the thing is done. So here are a few of the objectives I think should be sought:

• The whole system should be faster. That means testing should be faster, generation should be faster and as a consequence deployment should be faster. Right now testing is very slow, deployment is also very slow.
• The documentation system should target different customers. Right now there seem to be different sub-systems for testing, HTML (and 1 big page) generation, and the actual p6doc command which is supposed to be the main raison d'être, or at least the initial, for this system.
• Revision and matching with Perl 6/Rakudo releases should be automatized, or at least should have some automatic support. Right now the only way to spot mismatches is to wait for someone to find and report them.
• Making it independent of other tools would also be interesting. Right now Perl is used for serving the web site, and CoffeeScript for syntax-highlighting code.

So here are a few things I propose.

• The second and the first objectives piggyback on each other. We should create a cache system that indexes and stores a easily accessible representation of the documentation, which can then be used to render for different customers (present and future). This Pod registry should cache generated pages, which would include as metadata also from the original file they were generated, so that they can be invalidated when the original file has been changed (as a bonus, only the chunks that are actually affected by the change could be invalidated).
• Using Perl6::Parser could help us match Rakudo source and documentation.
• Additional tooling could check the file entropy and/or age and flag for revision those parts that could have been not revised for a long time.