chromatic, I think, in that big prove argument, pointed out that Test::More side-stepped the whole "shove all functionality into one interface" problem by creating Test::Builder. TAP::Parser and prove should go in the same direction.
Over and above simply being a way to build new test libraries, Test::Builder has two critical features above and beyond a simple subclass. 1) The resulting features can be added together. They play nice together. You don't have to choose just one variant. 2) There's a minimum of scaffolding necessary to create your own test library, especially now with Test::Builder::Module. This is easier to do with Test::Builder because custom features meant custom functions. Custom functions avoid functionality overlap and users write code specifically for them. Test::Harness and prove have no such luxury. I think with TAP there's two central desires. 1) Want to add / change functionality in Test::Harness or prove. For example, one that adds color, another that saves the TAP results, another that emails a report at the end of the test. 2) Want to come up with a radically different interface. For example, Test::TAP::HTML::Matrix. Or a GUI. How do you do this without balkanizing TAP::Parser into a bazillion mutually exclusive subclasses? Something like App::ProvePlus is right out, it's just shifting the dumping ground. -- Stabbing you in the face so you don't have to.
