My code is not that brute force. It does not try all possible opponent moves. It limits itself to checking whether each enemy piece can move to the King's position. So, it checks no more than one move per enemy piece. Second, it returns a true value as soon as the first check is found.

That is a very good method for most pieces. The problem is that I have to be completely general, as users can in principle define sliders that turn corners, such as the Sissa or the Hook Mover from the large Shogi variants. Such moves could come from anywhere, and they do not have to start in the direction of the King to hit the latter. Note that with the short-cut it is not that much 'brute force' anymore, because for each move it tests the legality of it selectively only tries the sliding moves that were hitting the moved piece as a reply. And most pieces were not attacked by an enemy slider at all, and for those you don't have to do anything. But the preparation step, to figure out what enemy slider moves are blocked, (done as a side effect of the test whether you are actually in check to begin with) is currently purely brute force.

I cannot even abort that when it does find a check, because I have to make sure it will detect every piece that blocks a slider. Otherwise it might use a pinned piece to interpose on the check. But that is no big loss: usually you are not in check, and then has to run the test to the end to conclude that. And it only doubles the effort compared to pseudo-legal highlighting: for that you have to generate all moves of the player that is on move anyway, and now you also have to do it for the opponent.

It sounds like this can handle riders, but what about hoppers or other complicated pieces? This reminds me of code I wrote just for Chess, which was optimized for Chess but couldn't handle every type of piece that might show up in a variant.

Indeed. Hoppers (or locust capture) are a pain. In principle the same method could be used if I also recorded for every square which hopper moves pass over it, and then recalculate these moves only as a reply to a move that lands on such a square. But there are typically many more empty squares you pass over than there are enemy pieces that block you, so that is a lot of overhead. (But there could be far fewer hoppers than other pieces in the game...) Application of the short-cut is controlled by a configurable parameter, and the only way to do fully-legal highlighting in a game with hoppers is currently to disable the short-cut. Which can make the preset annoyingly slow, as it would then do a full opponent move generation for every move. This is definitely something that begs improvement.

I guess a first step would be to tabulate which piece types are 'unpredictable', and classify hoppers (and imitators) as such. And then always try all moves of these pieces in reply to the 'move under test', but forget about the others (except for the pre-existing checks and the discovered slider moves).