The only "statement" non-terminal which ends on an "end" terminal symbol is a "compound statement". In other words, that particular "end" ends a compound statement.
yes but, "end" does _not_ start a statement.
The compiler doesn't look for a statement. It takes the next lexeme and tries to follow its current production rule.
The compiler better look for a statement, that's what tells the compiler the next production to execute. When the compiler sees a "begin" it looks for a statement which must be anyone of the symbols that start a statement of which "end" is _not_ one of them.
On the contrary: definition of statement includes the "end". The BNF rules are too many to include here, but the "statement" non-terminal definition is a recursive one, like:
<statement> ::= <simple statement> | <if statement> | ... | <compound statement>
Note <statement> includes <compound statement> and also <compound statement> includes <statement>.
Notice that in that BNF rule, there is no statement that starts with "end". "end" is part of a compound statement but, it is _not_ a token that starts a statement. It is neither found in <simple statement> nor in the start of <compound statement> or any other statement for that matter. "end" is not a statement, it is a statement list delimiter.
The separator is a term of the lexer. (What is a terminator?) The separators are whitespace and comments, they separate the lexemes. The semicolon is a terminal symbol in the BNF rules.
The semicolon is a terminal symbol but, _how_ it's used is what makes it a separator instead of a terminator. if the semicolon was a _terminator_ then the <statement> production would include the semicolon in it, instead in Pascal it appear in a production such as { statement } { ";" statement } if it were a terminator a statement list would specify statement as { statement ";" }. That is what makes the semicolon a terminator (as in C)
Putting a semicolon there will change the grammar from LL(1) to LL(k), k>1.
I cannot think of an instance where that would be the case. There is no reason for the compiler to have to backtrack because a semicolon terminates statements instead of separating them.
AFAIK, the FPC compiler uses a recursive descent parser, which is the main reason of its speed. Such a parser will need to backtrack if it can't decide which production rule to follow by just one lexeme (k>1).
FPC is a recursive descent compiler but, changing the semicolon from separator to terminator wouldn't affect that. It would affect the grammar but, it wouldn't create a situation where the compiler would have to backtrack (at least not in Pascal.)