Couldn't most of this be figured out by making Pod6 extensible (or whatever the right term is). Pod6 would be more of the syntax and basic operation, but other people could have custom directives that their Pod6 translators and formatters could then use. That is, not all of this has to be in the spec if the spec has a way to make it possible later. :)
Yes. That's exactly what we've done. Pod 6 has: =item a C<=use> directive that allows you to load behaviours for any user-defined blocks or formatting code you want =item a standard mechanism by which user-defined blocks are available (just make the block names mixed-case) =item a standard mechanism for adding new formatting codes (the M<> metacode)
And, as far as writing a new S26, does this mean that this really isn't open to discussion? That is, if we want something different than you want we have to have competing specs and there won't be any compromise?
Of course not. Indeed it's a *plea* for something more concrete to discuss, a suggestion of a way to get past the philosophical impasse of one group saying "this does everything you want", without nailing down the specifics of how, whilst another says "this isn't good enough", without clearly indicating what would be.
What I was actually suggesting was that this design *isn't* set in stone, and that the best way to convince Larry that the existing design could be better is to actually offer a better design.