I support this.  Tadziu's proposal seems well-considered (not a suprise).

I think the best would be a specification that allows sequences
of characters to be mapped to groff entity names, either in
terms of already-compounded entities (similar to what the
AFM file defines for PS glyph names, or what TeX does),

  ...
  charset
  ...
  ligatures
  f  i fi
  f  l fl
  f  f ff
  ff i Fi
  ff l Fl
  kernpairs
  ...

or looking at more than just the next input character,

  ...
  charset
  ...
  ligatures
  f f i Fi
  f f l Fl
  f i   fi
  f l   fl
  f f   ff
  kernpairs
  ...

The only thing that makes me uncomfortable about the above is that "ligatures" is already a recognized directive with pretty different parsing semantics.

    ligatures lig1 ... lign [0]
        Glyphs lig1, ..., lign are ligatures; possible ligatures are ff,
        fi, fl, ffi, and ffl.  For compatibility with other troff
        implementations, the list of ligatures may be terminated with
        a 0.  The list of ligatures must not extend over more than one
        line.

It would suck to break back-compatibility, might be fragile to maintain enough state to distinguish the foregoing while maintaining compatibility, and promises to be tedious to document such a Janus-faced directive so that users will understand it.

So I would pick a different keyword.