Ah, I see.  Thanks, Dave.

Yes, it looks like the parser's idea of what it's working on and the `chop` request's are getting out of sync.  That's pretty bad.

If I tackle bug #62264, we'll have a string iterator, and maybe `chop` can be re-implemented as a macro.  I already have visions of a new `string.tmac` file we can ship, with (relatively) often-requested services like `index` and `rindex` for locating a character within a string.

I had been wondering about use cases for reversing the order of a string iterator, and this is a significant one.

Hmm, from what I understand of character definitions, this is working as expected, and the defined-character object at the end of this string is being treated atomically--as an indivisible unit.

Reviewing our Texinfo manual...

 -- Request: .char c [contents]
 -- Request: .fchar c [contents]
 -- Request: .fschar f c [contents]
 -- Request: .schar c [contents]
     Define a new character or glyph C to be CONTENTS, which can be
     empty.  More precisely, 'char' defines a 'groff' object (or
     redefines an existing one) that is accessed with the name C on
     input, and produces CONTENTS on output.  Every time glyph C needs
     to be printed, CONTENTS is processed in a temporary environment and
     the result is wrapped up into a single object.  Compatibility mode
     is turned off and the escape character is set to '\' while CONTENTS
     is processed.  Any emboldening, constant spacing, or track kerning
     is applied to this object rather than to individual glyphs in
     CONTENTS.

     An object defined by these requests can be used just like a normal
     glyph provided by the output device.  In particular, other
     characters can be translated to it with the 'tr' or 'trin'
     requests; it can be made the leader character with the 'lc'
     request; repeated patterns can be drawn with it using the '\l' and
     '\L' escape sequences; and words containing C can be hyphenated
     correctly if the 'hcode' request is used to give the object a
     hyphenation code.

...it seems clear to be that `chop` (and other string-processing operations) should not be penetrating the boundary of the character definition, and correctly treat it as a character/glyph.

What do you think?

(I continue to feel that the spurious diagnostic in #64101 is well observed, and should be fixed.)