What this is trying to tell us is that
when we have an input of the form exp op exp op exp
(or ! exp op exp), when we see
the second operator, we don't know if the first op
should be reduced (because it has higher precedence
i.e. (exp op exp) op exp)
or if the second op should be shifted
(because it has the higher precedence
i.e. exp op (exp op exp)).

Finally, if we reexamine the grammar, we can see that the only way the second
parse can recognise a list followed by an id is if we can insert
an optcomma between them, which we can onll do by recognising an empty
optcomma:

so to get to state 4 we have read a list followed by a ',', and
we can not tell if this is an optcomma or not just by looking at the
next symbol (id) because the id can either belong to this
list (i.e. reduce rule 4) or it can belong to a surrounding
list optcomma id with an empty optcomma (i.e. reduce rule 3 then
rule 5) - in either case, we next shift the id and reduce rule 2.

i.e. the parse tree for an input of id , id can be:

i.e. ((id) (,) id)

or:

i.e. (((id) ,) () id) with two error messages:

extra comma ignored
missing comma inserted

The problem may be that we are forcing the parser to decide what to do with
the ',' too early on. We can try to delay the decision by getting rid
of the optcomma grammar rule and putting extra alternatives into the
rule for list:

i.e. after inputting and reducing a list, and shifting a ',' if the
parser then encounters another id, it does not know whether to
include this id in the current list (shift) or leave this
id to become part of a later list (reduce). i.e. the parse
tree for an input of id , id can be:

i.e. ((id) , id)

or:

i.e. (((id) ,) id) with the same two error messages as before

Looking at the possible parses, this is still pretty much the same problem as
before, so unfortunately the change we made to the grammar has not made any
real improvement.

Although we can't tell just from the error messages reporting the conflicts,
because we can create two alternative parse trees that both completely match a
possible legal input (i.e. id , id), this grammar and the previous
version are both ambiguous, and can never be recognised correctly by a parser
tool.

The only thing to do is to take a step back and describe afresh what we are
trying to recognise. I will concentrate on the identifiers, as they are what
we are really interested in. We want to recognise a list of identifiers,
each pair separated by zero or more commas (although we expect exactly one),
and the whole list perhaps preceded and trailed by some commas (although we
expect none):