Yes, this is OGS’s bug.
My guess is that OGS’s code attempts to implement the parsing of two different move encodings using the same code at the same time:
- GTP move encodings and which KataGo’s analysis engine also conforms to. This is the move encoding for the standard protocol for live Go engines, Go Text Protocol (which as an aside, was not forward-looking in a few different ways that make it unfortunate that it became the standard protocol). These moves look like “D3”, “Q16”,… and where the letter coordinate is mandated by the protocol to skip the letter I. Pass is defined to be the string “pass”, and A1 is the lower left corner of the board.
- SGF move encodings. This is the encoding mandated for SGF files. These moves look like “dc”, “pp”,… where both coordinates use letters, and are mandated not to skip the letter “i”. Pass is defined to be the empty string “” or the string “tt” for boards < 19x19 as a special case, and “aa” is the upper-left corner of the board.
I’m guessing OGS’s code, by trying to parse both of these coordinate systems within the same function, when it receives “pass” from KataGo, it reads the first two letters and ignores the remaining letters, decides that this must be an SGF move encoding “pa” instead of a GTP move like the rest of KataGo’s output, and “pa” in SGF corresponds to Q19 in GTP.