UTF8 with BOM

[RenamedPlayer]

Tested with document.cpp and it's complement document.h.
If document.cpp is saved as UTF8 without BOM, everything works fine.
If the .cpp is saved as UTF8 with BOM, it's first #include is ignored by b2, if the file starts with that (just after the BOM, sure).
„Ignored“ means not in the depency tree showed with -d3, so document.cpp is not recompiled on change of file to be included, here document.h.
That is repeatable, but not tested with other files.
B2 5.2.0 (OS=NT, jobs=12)

[RenamedPlayer]

After a break I think that the program does ignore the line following the 3 bytes of BOM up to the next line break.

[grisumbras]

This isn't really surpring, given that the scanner regexp is this:
https://github.com/bfgroup/b2/blob/main/src/tools/types/cpp.jam#L33

^[ \t]#include means that the line should start with #include (potentially prefixed with whitesace), with BOM it starts with some non-ASCII garbage.

As a temporary solution I can suggest putting copyright attribution comments at the top of your files 😉.

[RenamedPlayer]

Copyright not needed, // bjam Special.
I see, BOM is rarely used, I had the new to me Notepad++ quasi instantly crashed with that.
And consider all the mystical variants, that no one uses,

#   incl\
ude \
    <hall\
öch𒁣en.µ>

Uuuh, the compiler does it. Hehe.
No no, only simple is reliable. But to document the known simpliness would be fine.