This side effect is also true for Precedence items, and for the same reason, since now they always result in a unique node (an operator expression, or a primary expression), they don't have to produce their own top-level nodes. From the design doc:

It is important to note that the item name doesn't contribute a NonTerminalKind, but each PrecedenceExpression under it contributes one.

Could you elaborate a bit which side effect are you referring to here?

I was commenting on:

Maybe it'd be better if we somehow allow to "outline" select enums in v2, like this one? @OmarTawfik

Are you suggesting this just for testing? I think I will have to introduce strongly typed parseEnumFoo() -> EnumFoo at some point anyways. We can test its root node, even if it wasn't wrapped with an explicit NonTerminalKind. Thoughts?

I was also mentioning that like Enum items, Precedence items also don't produce their own NonTerminalKind, but their inner precedence_expressions entries do.

Right, I wanted to specifically say that being able to parse a general construct like "expression" or "statement" seems like something we want to do anyway, even if it doesn't have a dedicated rule kind in the CST (is inlined), so the future parseEnum approach answers my concern.