You cannot use the variable 'checked' the way your code does (in the functions K and k), because the betza.txt include file does the mate test before the check test (which sets this variable). As a result the variable 'checked' is undefined during the mate test, which apparantly is interpreted as not being in check. So the mate test thinks the King, still in its initial position, can use its initial jumps to escape the check, and hence does not see it as mate.
There currently isn't a good alternative. Perhaps all initial moves of a royal piece should be forbidden when in check. Castling is forbidden when in check, but this is implemented as a property of the castling rather than of the fact that it is defined as an initial move. The mechanism by which this is implemented is that castling creates e.p. squares along the path of the King, including the starting square. And that any move to an e.p. square will always (locust-)capture the royal piece, if that was the last-moved piece. (Otherwise only e.p.-capable pieces would perform the capture.) So what really should happen here is that the initial King moves create an e.p. square on the original King location.
[Edit] This e.p. trick for detecting moving out of check after the fact unfortunately does not work in general: a King could make a leap towards a hopper, and therby activate the hopper for capture to the square it just left. While it would not have been in check by that hopper if it had stayed there. For castlings this cannot happen, as there will also be a Rook in between King origin and any piece that would be standing outside of the Rook. Although a bent hopper might be activated by the Rook. An enemy Grasshopper outside of the Rook would attack the Rook after castling, which could lead to the accusation of having castled through check. Or, when the King would end next to the Rook's original square, to moving through check on its destination square, which would no longer be checked after the castling.
You cannot use the variable 'checked' the way your code does (in the functions K and k), because the betza.txt include file does the mate test before the check test (which sets this variable). As a result the variable 'checked' is undefined during the mate test, which apparantly is interpreted as not being in check. So the mate test thinks the King, still in its initial position, can use its initial jumps to escape the check, and hence does not see it as mate.
There currently isn't a good alternative. Perhaps all initial moves of a royal piece should be forbidden when in check. Castling is forbidden when in check, but this is implemented as a property of the castling rather than of the fact that it is defined as an initial move. The mechanism by which this is implemented is that castling creates e.p. squares along the path of the King, including the starting square. And that any move to an e.p. square will always (locust-)capture the royal piece, if that was the last-moved piece. (Otherwise only e.p.-capable pieces would perform the capture.) So what really should happen here is that the initial King moves create an e.p. square on the original King location.
[Edit] This e.p. trick for detecting moving out of check after the fact unfortunately does not work in general: a King could make a leap towards a hopper, and therby activate the hopper for capture to the square it just left. While it would not have been in check by that hopper if it had stayed there. For castlings this cannot happen, as there will also be a Rook in between King origin and any piece that would be standing outside of the Rook. Although a bent hopper might be activated by the Rook. An enemy Grasshopper outside of the Rook would attack the Rook after castling, which could lead to the accusation of having castled through check. Or, when the King would end next to the Rook's original square, to moving through check on its destination square, which would no longer be checked after the castling.