Funny behavior in RDi/SQL formatter

I start with a nice, clean piece of code in RDi 9.6.0.10 running on an
up-to-date Win10 Professional ThinkPad:

:ad1desc; --Description

if sqlstt = SQLGoodRead;
//Good read

qd1eff = zzr000_d8a(ad1eff);
qd1can = zzr000_d8a(ad1can);
qd1desc = ad1desc;

if %date >= ad1eff
and (%date <= ad1can or ad1can = d'0001-01-01');
*in52 = *on;
else;
*in52 = *off;
endif;

s01rrn = s01rrn + 1;
//Subfile RRN

write r90wd01;

else;
//Otherwise

*in35 = *on;
// Turn off "More...

endif;

enddo;

And press Ctrl+Shift+F and get this dog's breakfast of weird indenting and
upper-cased opcodes:

:ad1desc; --Description

IF sqlstt = sqlgoodread; //Good read
qd1eff = zzr000_d8a(ad1eff);
qd1can = zzr000_d8a(ad1can);
qd1desc = ad1desc;
IF %date >= ad1eff
AND (%date <= ad1can
OR ad1can = d'0001-01-01')
;
*in52 = *ON;
ELSE;
*in52 = *off;
endif;
s01rrn = s01rrn + 1; //Subfile RRN
WRITE r90wd01;
ELSE; //Otherwise
*in35 = *ON; // Turn off "More...
endif;
enddo;

EXEC SQL
CLOSE gpr90w_gpp090_cursor;

qpos01 = 1;

q_format = 'tag400';
leave;

enddo;

The behavior is intermittent. The code is straightforward to the point of
being boring and without any hinky formatting in previous lines. The
problem is not resolved by a reboot. I have received messages indicating
"indenting past column 80 not allowed" and that message appears to end
the reformatting process (that problem was caused by a 3rd party conversion
tool's problem with handling comments and indented code).

My guess is that the formatter doesn't know to quit when the last line of
the program variables list has a comment, like this:
:ad1desc; --Description

Almost all of my SQL code is machine-generated and my programs may have
broken a rule by having an SQL comment *after* the semicolon. Let's see if
that's the cure.