Consider:

from pyparsing import Literal

cont = Literal("word").setName("cont")
g = (Literal("single")
    | Literal("double") + cont).setName("spec")
print(g.parseString("double hord", parseAll=True))

This will raise a parse exception with the message

Expected spec, found 'h'  (at char 7), (line:1, col:8)

– and I consider that highly confusing; it should IMHO have said

Expected cont, found 'h'  (at char 7), (line:1, col:8)

(i.e., name the failing nonterminal) or perhaps

Expected spec, found 'h'  (at char 0), (line:1, col:0)

(i.e., at least say where it tried to match spec).

Looking at MatchFirst's parseImpl, I see

           if maxException is not None:
                maxException.msg = self.errmsg
                raise maxException

(where maxException is the exception raised by the alternative that went the farthest here). That looks quite like this is desired behaviour – but I can't see why it should be: Wouldn't this always give confusing messages whenever a MatchFirst alternative fails a few tokens into its rule?

Given this has been in pyparsing basically forever (I traced it back to 2012), I'm seriously doubting my sanity here, but I can't see what I'm getting wrong...