I wonder if it would suffice to check the legality of the newest move only.
That is what the code used when you generate rule enforcement through the play-test applet does. But it doesn't do it in the Post-Game section, but conditionally skips the full test in the Post-Move section (in the routine HandleMove). It does this by comparing the variables mln and $maxmln, which are equal for the latest move.
The point is that the code in the Post-Move section will update the game state (by performing the move). So the Post-Game code is only executed after the latest move has already been performed. And it is a bit cumbersome to test the (pseudo-)legality of a move after it has been made. The (pseudo-)legality might depend on aspects of the game state that were not reversibly updated. Like e.p. or castling rights, side-effect captures of an Ultima Withdrawer or Long Leaper. It was much easier to test the legality of the move before it is made.
The processing of the non-latest moves was already quite similar as that of the latest move anyway, due to the requirement to handle moves with implied side effects (such as e.p. captures and castlings). To make that possible it was necessary to generate a list of all such moves (including their side effects), and then pick out the one with the origin and destination that matches the input, to supply the unspecified actions that have to be applied to the position to perform the move. For the latest move all pseudo-legal moves are generated, rather than just those with implied side effects, so that it can easily be tested whether the input move is amongst those.
This only applies to the testing of pseudo-legality. Testing whether the move is truly legal (i.e. did not expose the royal to capture) is something that is more easy to do after the move has been made, and thus is performed in the Post-Game section.
That is what the code used when you generate rule enforcement through the play-test applet does. But it doesn't do it in the Post-Game section, but conditionally skips the full test in the Post-Move section (in the routine HandleMove). It does this by comparing the variables mln and $maxmln, which are equal for the latest move.
The point is that the code in the Post-Move section will update the game state (by performing the move). So the Post-Game code is only executed after the latest move has already been performed. And it is a bit cumbersome to test the (pseudo-)legality of a move after it has been made. The (pseudo-)legality might depend on aspects of the game state that were not reversibly updated. Like e.p. or castling rights, side-effect captures of an Ultima Withdrawer or Long Leaper. It was much easier to test the legality of the move before it is made.
The processing of the non-latest moves was already quite similar as that of the latest move anyway, due to the requirement to handle moves with implied side effects (such as e.p. captures and castlings). To make that possible it was necessary to generate a list of all such moves (including their side effects), and then pick out the one with the origin and destination that matches the input, to supply the unspecified actions that have to be applied to the position to perform the move. For the latest move all pseudo-legal moves are generated, rather than just those with implied side effects, so that it can easily be tested whether the input move is amongst those.
This only applies to the testing of pseudo-legality. Testing whether the move is truly legal (i.e. did not expose the royal to capture) is something that is more easy to do after the move has been made, and thus is performed in the Post-Game section.