I'm sure you could only have one lexer back at some point in the distant past, but that particular issue has been solvable for a long time by now.
But in general, for anybody deploying software widely, any time you can avoid a necessary build dependency on another tool, you come out ahead.
https://www.gnu.org/software/bison/manual/bison.html#Version...
Even if you have standard-conforming lex and yacc source code that, theoretically, work with any yacc or lex implementation, it's still wise to pick a good implementation and generate code with it, and ship that code. You don't want some random tool from the user's installation writing C code into your project.
And POSIX does not guarantee the presence of a yacc command in an installation; it just describes what it does if it is present. There are Unix-like systems with no dev tools on them; requiring lex plus yacc plus a compiler is a bigger dependency than just requiring a compiler.
People writing C++ code no longer have any need for a thing like yacc, and that is a net good.
Those who maintain some relationship with the cpgg upstream repo have some sort of dependency.
(C++ itself is a heavy dependency. People who don't use C++ demonstrate that C++ is not necessary.) Dependencies are not all the same; they have different weights. Three light dependencies could be equal to one heavy one.)
cpgg is currently not comparable to something like Bison. Bison has documentation, and an active mailing list where you can get quality help from knowledgeable people. It has multiple contributors.
It supports multiple languages, so your parser-writing skill transfers to different stacks: e.g. from C to Java, for instance. In many cases you should be able to port the grammar directly; just the semantic actions need a rewrite.
It has some novel diagnostic features, like the recently added feature of being able to generate counterexamples to explain conflicts.
It has the old diagnostic features, like the y.output file so you can pore over the LALR(1) state graph, and a debug mode.
It supports something called "push parsing": inverting the control flow, so that the parser becomes a state machine to which you can feed tokens one at a time. That makes it possible to do things like, oh, multiplex multiple parse jobs in parallel into a single event loop.
What bug database are you using: I don't know of any ISO-standard bug database.
Git is not an ISO-standard; do you pass around pax archives for version control? Not using SSH, I hope; that's not ISO standard.
Not even XWindow is an ISO standard, so nothing but ANSI terminals for you.