Haru's Diagram doesn't implement this game by change of piece type. It gives the pieces the same move set everywhere. But with moves that are making such complex detours that the unwanted moves will not be possible because they stray off board at the wrong step along their trajectory. This makes the move descriptions in the piece table totally uninterpretable for humans, and the I.D. thus a failure as an aid for explaning the rules. One can say that the program here uses the concept of pieces with a fixed set of very complex detour moves. For this game this seems a very cumbersome way to think about it, and it is hard to imagine that a human would be able to understand it, let alone prefer it.

But that is not the case for all games that can have different conceptual interpretations; for Xiangqi it makes very little difference in conceptual complexity whether you consider the Pawn to have a location-dependent move set, or that it promotes to another type on crossing the River. It probably depends on the player's background; Chess players are used to promoting Pawns, Smess players will be used to location dependence. Shogi players will be used to the concept of pieces having an 'internal state', and are more likely to see even promotion as merely a different micro-type of the same piece, which is the physical tile that can get flipped.

I only entered this dscussion to investigate whether it wold be possible to base an I.D. on a concept that is more useful for humans than the detour moves, so that it could not only play by the rules, but actualy present those in a helpful way. At least the concept of type change on arrival on each square would cause a more intellegible presentation of the moves (which would become the usual leaps and rides, rather than detour trajectories that stray over the board edge). The disadvantage in this case would be that it involves so many different types.

I think you are mainly turned off on this conceptual interpretation of the rules by that I happened to call these 'types'. But it is really not different from what you describe, that the same piece acquires a different set of moves when it lands on a square. The only difference is that what I called micro-types you call move set. But that is not a conceptual difference, it is just different terminology. Smess (as well as Xiangqi, Elk Chess, Avatar and Bull'sEye) happens to be a game where the current move set of a piece is completely determined by the square it last landed on. Chess promotions do not have that, and we tend to think of the pawn becoming of another type. (Even though in over-the-board Bughouse rules it retains the physical shape of a pawn, and players just have to remember how it moves.) In Shogi it is most clear that the same piece can have two different micro-types/move sets.

The I.D. currently only understands piece types as move sets/micro-types, and lists every micro-type as a different entry in the piece table, with its own fixed move set. For a Smess implementation using the micro-type concept that would give a very lengthy table. (But with simple moves.) It gives little indication which of these micro-types are just different move sets for the same macro-type. So I think it would already be an improvement if it would represent the macro-types as single entries in the table, and allow those to be defined as a macro-type (with multiple move sets) in the Diagram definition. E.g. for Elk Chess we could define

elk:E:R,N:pegasus:a1,h1
microTypes=ab/ba/"/"/"

(where ab expands to abababab to fill the rank, and the double quotes repeat the previous two ranks). That is simple enough, but the problem with Smess is that you still would need a quite long list to describe how, say, a Numskull could move on all the different squares. The number of move sets could be reduced by realizing that many are merely different orientations of others, but that would be hard to exploit, as you still would have to specify somewhere what orientation applies where. And it is very specific to Smess, where the location affects only the allowed directions of the move. So it would be something you would do in a dedicated Smess (or StIT) program, but not be generally useful enough to make it worth implementing in general-purpose chess-variant software.