Affects groff 1.22.4.  Appears to go all the way back to this feature's introduction in commit d239103a7b, 3 February 2007.

"big" is documented as a primitive, but it doesn't work that way.  Instead it is contextually meaningful only after a "size" primitive.

And, moreover, only when MathML is being generated.  It causes havoc in groff output.

$ cat EXPERIMENTS/eqn-use-big.roff
.EQ
big sin x
.EN
.EQ
size big sin x
.EN
$ eqn -TMathML EXPERIMENTS/eqn-use-big.roff
.if !dEQ .ds EQ
.if !dEN .ds EN
.EQ
<math><mrow><mi>b</mi><mi>i</mi><mi>g</mi><mstyle mathvariant='normal'><mtext>sin</mtext></mstyle><mi>x</mi></mrow></math>
.EN
.EQ
<math><mrow><mstyle mathsize='big'><mstyle mathvariant='normal'><mtext>sin</mtext></mstyle></mstyle><mi>x</mi></mrow></math>
.EN
$ eqn -Tascii EXPERIMENTS/eqn-use-big.roff |nroff -Tascii | cat -s
troff: EXPERIMENTS/eqn-use-big.roff:14: warning: numeric expression expected (got 'b')
bigsinx sinx
$ eqn -Tascii EXPERIMENTS/eqn-use-big.roff
.if !dEQ .ds EQ
.if !dEN .ds EN
[...]
.nr 0w2 +\w\(EQ\,b\&i\&g\/\,x\/\(EQ
[...]
.as1 10 \&\E*[0sfont]\f[I]\s'\En[0ssize]u'\,b\&i\&g\/\h'17M'\f[R]sin\f[\n[0f5]]\h'17M'\,x\/\E*[0rfont]
[...]
.ps big \" GBR: !!!!
[...]

(You might notice that the line number in the diagnostic is off.  This is due to eqn itself producing invalid groff input, for which line numbers are generally not reliable because `lf` requests must be used to align those numbers with user expectations.)