OK, thanks. The object hierarchy may be what it is now, for good or ill.

I understand, naming things is hard and its not like I have better ideas, I still have puns (chits) in my code; you saved me so many months of work I'm just surprised you didn't go the extra mile :D I think I'm worth the effort , don't you? :P

But to the extent I understand your code it is not only a documentation of PPIx::Regexp bugs, but a neat piece of work in its own right.

:D

Which of the bugs can I fix without breaking your code?

Now, I think you can fix all of them without breaking anything :) that is if they are bugs, bugs you'd consider fixing ; I think I tended to use "bug" as euphemism for "now I have to think some more" ...

Do I need to reserve some method names for your use? Like xplain()? I'm not sure how to document it, but I'm willing at least to avoid a few that you designate.

Not sure that you actually have to reserve them , but xplain prefix sounds ok ... i'm very unsure about the whole what/should/go/where/oop deal, some would say don't play with other peoples namespace :)

Can you be a little clearer on the modifier propagation thing?

Hmmm, I'll try
/(?i)foo/ is same as /foo/i, but the "foo" node doesn't know its case insensitive
/foo/aad says semantics are "d" but "aa" and d are mutually exclusive (regexerror++)
/\w/aia says semantics are "a" but "aa" and "a" are different

So I guess its more of a wishlist; I tried to propagate parent modifiers to children using ->modifiers but ->modifiers discarded some information (like errors), so I ended up doing my own exploding :) I also guess the xplicit propagation might not fit with the purpose of tokens, so PPIx::Regexp wasn't doing propagation of modifers, so not much for you to do regarding propagation :)

Thanks