Our Texinfo manual says (after some recasting presently in my working copy):

     The margin character is a property of the output line; the margin
     character last configured when the line is output controls.  If the
     margin character is disabled before an output line breaks, none is
     output (but see below).
[...]
   For compatibility with AT&T 'troff', a call to 'mc' to set the margin
character can't be undone immediately; at least one line gets a margin
character.

     .ll 10n
     .nf
     .mc |
     .mc *
     .mc
     foo
     bar
         => foo        *
         => bar

It appears that GNU troff uses two separate flag bits to keep track of this business, "on" and "next" (as usual, James Clark's naming practices are not transparent to me).

It would be nice to reconceptualize this phenomenon as margin character "stickiness", such that, if the margin character is "sticky", you can change it but not remove it for the current output line, and not merely have this be a quirky property that attaches only to the first output line affected by an `mc` request enabling a margin character.

I think exposing this might also help programs like gdiffmk with a problem that has long afflicted them.  I can't find where I saw this right now, but I've seen what seemed a fairly important standards document (knowing me, probably for Ada or POSIX) that apologized for its change bar tool having an off-by-one error.   I think this had to do with an output line ending a paragraph either getting a change bar when it shouldn't have, or vice versa, and the problem arising from the fact that a change occurred on a source line that wasn't the last in the paragraph.

If I'm right, that would make the change worth it.

An interface to margin character stickiness might be in supporting a third argument to `mc`.  A case against would be that people might want to manipulate stickiness separately from the character itself or its placement (and making them retype these things opens avenues for error).

Another avenue would be to add a request, maybe `mcsticky`, which would work like `linetabs` and `vpt`, and interpret a Boolean value: >0 on, otherwise off.  I guess I'd be morally compelled to add a read-only Boolean-valued register `.mcsticky` to reflect the state.

I also wonder if we could get away with dropping AT&T compatibility altogether for this behavior, since it is so specialized.