I haven’t spent enough time looking at <leftop> although I am given to understand that the (s /;/) syntax is supposed to be equivalent...

One issue that, as I now recall, was one reason for my latching-on to tail recursion ... was error messages.   If there was an error somewhere some statement, deep down in the file, the only error-message that actually popped-out was from the <error> production of the outermost rule.   I freely admit that I think I have built stuff that “works, sort of ...”   Well, actually it works very well, in terms of the results that it now allows us to obtain.   But I know that it was not built properly and I would like to fix it now rather than later.   Yes, I am running this thing on a machine that’s big enough to run 20 or more SAS® jobs at once.   But, because the results are already well on their way to being “mission critical” for this workgroup, I know that insufficiency in these parsers will definitely come back to bite me soon.

Can anyone point me to some really good, in depth material on substantial applications/case-studies of Parse::RecDescent?   I need to sip from a firehose on how to really use this thing right.   I need to read war-stories in detail.

I presume you have

{
   use strict;
   use warnings;
}
[download]

inside your grammar. Add

no warnings 'recursion';
[download]

to that block.

You are precompiling, right? You can see the generated parser by looking at that .pm file.

How about something like:

{
my @stmterrs;
}
DDL_stmtlist: DDL_statement(s? /;/) {
    if (@stmterrs) {
      push(@{$thisparser->{errors}}, @stmterrs);
      undef;
    } else { 1; } }

DDL_statement: whatever
   |  {
       push(@stmterrs, ["something fishy", $thisline]);
      } <resync: /[^;]*/s >
[download]

DDL_statement will now "succeed" until the end of the input. But you get to keep every error you encounter along the way.