antlr4 empty alternative not working as expected - antlr4

Question

I'd presumed that in general the rule
rule: ( something ? ) ;
could generally be expressed as alternation with nothing, with identical semantics
rule: ( something | ) ; <-- empty alt here
(provided of course 'something' is a single item or bracketed to make it so). It seems obviously correct but antlr4 isn't having it. This code does as I expect
version 1, works
opt_cursor_into_spec :
( cursor_into_spec ? )
;
cursor_into_spec :
INTO
sident ( COMMA sident ) *
;
but this doesn't; failing to parse the input:
version 2, fails
opt_cursor_into_spec : // this rule's changed
cursor_into_spec
|
// empty alt
;
cursor_into_spec : // this is the same
INTO
sident ( COMMA sident ) *
;
Here's part of the diagnostics trace on version 2, note the [***]
consume [#1,8:11='crsr',<483>,2:6] rule regular_ident
exit regular_ident, LT(1)=<EOF>
exit sident, LT(1)=<EOF>
exit cic_cursor_name, LT(1)=<EOF>
exit cursor_ident_clause, LT(1)=<EOF>
enter opt_cursor_into_spec, LT(1)=<EOF>
line 4:0 no viable alternative at input '<EOF>' [***]
exit opt_cursor_into_spec, LT(1)=<EOF>
exit fetch_statement, LT(1)=<EOF>
exit sql_item, LT(1)=<EOF>
enter opt_sql_separators, LT(1)=<EOF>
exit opt_sql_separators, LT(1)=<EOF>
exit sql_items, LT(1)=<EOF>
This is odd as at *** it claims no viable alternative, but at the line before it says it's entered into opt_cursor_into_spec, but this rule has the empty alternative, which surely always matches - one can always match the empty string, I thought?
So is my assumption of this equivalence...
( x ? ) === ( x | <<<nothing>>> )
...incorrect, or what?
This Q isn't about code, but about my understanding of semantics. If anyone thinks these should do the same, I'll try to post reproducible code.
Edit: More confused now. A stripped down grammar didn't reproduce. Something about the end of file was suspicious as the input to parse is just fetch a and it seems to get parsed in full according to the diagnostics trace, then fails. Hmm. I added an explicit EOF to the starting rule, so (a bit simplified)
sql_items : sql_item * ; // ORIGINAL
became
sql_items : sql_item * EOF; // NEW
And both (x? and x|<<<nothing>>>) suddenly work for NEW. Previously only x? worked for ORIGINAL.
Adding an EOF test should surely not cause a previously unsuccessful parse to succeed, can it?
Edit 3: edit 2 struck as it was misleading and unhelpful
Edit 2: on reflection adding EOF to the grammar can of course cause a previously successful parse to fail, as an input can be well-formed at the start but malformed as a whole (ie. imagine parsing an expression 2 + 3 £$%&, the start is valid but overall it's crud) but that's not apparently what's happening here.

Answer 1

In version 1, the rule opt_cursor_into_spec matches iff the rule cursor_into_spec matches. In version 2, the rule opt_cursor_into_spec will always be matched. So the semantics of the grammar, specifically due to rules that have opt_cursor_into_spec as an element, will differ.
Likely, in version 2, you are getting a compile time warning about a rule that can match anything. You cannot ignore the warning unless you really understand the cause and effect.