The problem of moves eclipsing each other has always existed. Usually it can be ameliorated by reordering the moves in the XBetza descriptor. E.g. DR would show the same move diagram as a plain R, and if you want the possibility to show that the 2nd square can be jumped to you would have to write RD. I recently improved this slightly by combining m moves from one atom with c moves from a later atom, to show up as normal destinations. so that mQcK would show the K targets as having both m and c.
The Seireigi Falcon and Eagle are also outlier cases. Their move-only parts are part of a locust capture, so I was unable to eliminate the problem completely.
Perhaps the Highlight function can highlight squares based on a hierarchy, such that if the program is told to highlight a square, it will replace the current highlight color if the highlight has a in precedence, or keep it the same if the highlight is of lower presence. Such a system would all but eliminate this problem, regardless of what move generator is used. A few outlier cases may remain, but they would be very few and very far between.
The Seireigi Falcon and Eagle are also outlier cases. Their move-only parts are part of a locust capture, so I was unable to eliminate the problem completely.
Perhaps the Highlight function can highlight squares based on a hierarchy, such that if the program is told to highlight a square, it will replace the current highlight color if the highlight has a in precedence, or keep it the same if the highlight is of lower presence. Such a system would all but eliminate this problem, regardless of what move generator is used. A few outlier cases may remain, but they would be very few and very far between.