This was also my first thought, in perhaps more confused language than snarky, though.
The use of emojis looks quite similar to the way parameter/argument labels are introduced in Swift: in the function signature, you use two names (separated by a space) before the colon, instead of one. So, is this second part a shorthand alternative name, or just a visual comment, or?..
ENTITY_DECLARATION ::= NAME [SPACE COMMENT] COLON ...
ENTITY_DECLARATION ::= NAME [SPACE SINGLE_EMOJI_COMMENT] COLON ...
ENTITY_DECLARATION ::= NAME1 [SPACE NAME2] COLON ...
ENTITY_DECLARATION ::= REGULAR_NAME [SPACE EMOJI_NAME] COLON ...
Don't get me wrong, I am not opposed to emojis on principle, they are just 1) a tad too outstanding in the text for my taste, 2) a tad too difficult to enter unless you're on a mobile keyboard, 3) I personally would rather not edit program source code/configs on mobile.
Windows and macOS both have great on-screen keyboards (OSK)/input method editor (IME) for emoji. Many (most?) Linux desktop environments also provide one. On Windows it is Win+. or Win+; and on macOS it is Ctrl+Cmd+Space and on Gnome it is Ctrl+Shift+E,Space or Super+E.
Bwahahaha. Sorry, I’ve just imagined the poor sod who has to implement this grammar and has to decide whether presentation selectors or (potentially unknown) ZWJ sequences or (potentially unknown) letter-pairs denoting flags count parts of as single emoji (in theory they do[1], but good luck figuring out what tables you need).
> the way parameter/argument labels are introduced in Swift: in the function signature, you use two names (separated by a space) before the colon, instead of one
Side note: Swift’s style likely comes from Objective-C, which in turn comes from Smalltalk.