I have implemeted the idea now to show potential hops in the move diagram as a separate symbol. (Currently I use the same marker as on the board is used for King moves that step into check. Which is also a case of "possible under other circumstances".) It doesn't really produce the desired effect; on the Grasshopper it is OK, but the betza1 piece was defined as an enhanced Pao, mRpcR. And because the move-only access to a square is defined by a different Betza atom as the hop possibility, the latter overwrites the former. So the information that non-captures to these squares are valid moves is lost...

This is a manifestation of a more general problem: what if the same square can be reached for different purposes? Currently only the last generated highlight survives, and I leave it to the user to decide what this should be (by writing the order of the various moves). By writing the Pao as pcRmR the potential-hop marker would be overwritten by the move-only marker. So far that didn't cause any problems in practical cases. E.g. a Rook that also jumps to the second square should be written as RD, and not as DR, so that the D jump overwrites the sliding move, and remains visible. You don't have to know that you could go to the same square through a blockable move if you can get there with a leap, after all. If you had a RmD it would be problematic, though. The capture to the second square is now blockable, the non-capture is not. There is no symbol for that combination of moves. For overlapping riders it is even more hopeless: suppose you had a Rook-Dababbarider RDD. It would show up the same as a Rook, which suggests that distant moves can be blocked on squares closer to the piece. That is true for access to the odd squares, but access to the 4th square (say) is not blocked by an obstacle on the 1st or 3rd square (because the DD leaps over those), but it would be blocked by an obstacle on the 2nd square. Having separate symbols for such weird situation is not productive, I think.

Giving the markers a black outline improves visibility on an e-ink screen. For something like the Cannon, you might separate two different markers by a slash. The slash could represent a screen, and one marker could indicate a move possible before the screen, while the other could indicate a move possible after the screen. For a Cannon's one-step move, the marker for a non-capturing move could be used by itself.

I am afraid this will get too complex to still transfer information. In general you cannot fully desribe every potential situation in a static picture. Suppose you had a piece like Mats' bifurcators, which change direction after (or before) colliding with a screen. There the number of squares you could reach if there was a screen in an undetermined position fills an entire sector of the plane, and it would be completely obscure what position a screen would need to be at to reach a particular potential target.

So I think the purpose of the markers should merely be to warn the user that something tricky is going on which would alter the picture in an unexpected way if the square was occupied. (The expected way being that it blocks the ray, and all symbols identical to it 'downstream' would just disappear.) Not to encode in detail what it is that would change. That the user can discover interactively, by indeed putting something on the marked square. He can already do that in the setup diagram, by moving pieces into a similar constellation, but a simplified possibility could even be added in the move diagram through the 'hover trick'.

That being said, it still seems bad to have a move diagram of a Pao only show non-captures without a hint of hopping, or only show hop locations without a hint it could simply move there. (A similar situation occurs in Quan Trung Chess, where there is a "grasshopping Rook locust"). So perhaps the potential to hop should not be indicated by a marker, but by a grey background color, so that it can combine with any marker, rather than erasing it. The move diagram is not checkered, so it would be the only deviating background color, so no problem on a grey-scale device. And when background color is the main method of highlighting, it could draw the grey cross marker in the hop squares.