Why isn't bitand properly parsed to form an rvalue reference?

Question

An rvalue reference could be formed using an alternative token:

int and i = 0;  

It could also be formed after splicing physical source lines to form logical source lines:

int &\
& i = 0;

So why doesn't the following program compile?

int main() {
    int &\
bitand i = 5;
}

Based on the standard, I don't see why it shouldn't.

[lex.digraph] In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling.

[lex.phases] Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice.

Is there additional information that I missed, or is this a compiler bug?

Answer 1

The backslash+newline sequence is a red herring. These things are removed before the tokenization phase (that's phase two and phase three of the translation, respectively). We can thus concentrate on these fragments instead:

&&
&bitand

The first line has one token, &&. The second line has two tokens, & and bitand. The last token is equivalent to & so the second line behaves exactly as if it contained two & tokens. This is different from one && token. The latter is composed of two & characters, not two & tokens.