The issue is that Smess is really a game with very complex rules (which only becomes a problem if you want to express those in a simple way). The way you programmed it also requires an array of 90 8-bit numbers describing the square properties. For humans these properties are given through a picture of the board (so they won't even have to memorize those), and as we know a picture paints a thousand words. Computer programs cannot read pictures, though, so there we have to supply the thousand words...

Your solution can be so convenient, because it is a dedicated program for Smess, and thus can exploit some properties that are peculiar to Smess. Namely that the piece location only affects the directions you can move in. That would not hold for, say, Avatar, where the range and the move step are determined by the location, rather than the direction. Of course you could make a dedicated solution there too, where the square properties specify whether the move is N, K, R, B or Q.

In general what one would have to supply is a move set for every square, and that for every piece type, as not in every variant we will be so lucky that Numskulls and Ninnies on the same square must also move in the same directions. Specifying an array of 90 'direction sets' will be hardly less effort than giving 90 full Betza specifications of the move sets; exploiting that only the direction set is determined by the location allows you to omit the atom from the Betza descriptor, but that is just a single letter, while specifying the direction set will usually require several letters.

If one includes the specification of the board properties your GC solution is not so convenient at all, because each of the 90 properties requires a multi-character definition, hardly shorter than a full Betza move specification. For humans this complexity is hidden by painting this information in graphical form on the board.

It would be easy enough to allow specification of a location-dependent move in the I.D. by supplying a comma-and-slash-separated list of Betza move descriptors in a FEN-like organization, one move descriptor for every cell of the board. One could even use the short-hands discussed earlier, so the move of the Elk could be written as R,N/N,R/"/"/" instead of supplying moves for all 64 squares, but for Smess that would offer no relieve.

Space attributes are supported in the I.D. through the morph parameters that can be defined for each piece. These can specify all properties a piece type can have in a square-dependent manner. But it specifies these properties by a single letter, namely the piece ID, referring to a type-definition line that assigned this ID. This is in general more efficient, because usually many board squares would have the same properties, and repeating the full description of those properties for all of those would make the Diagram definition needlessly verbose.

One might argue that the Diagram's type definitions also specify image and name, and that these should remain the same on all squares, and thus are now needlessly repeated. But this is debatable. E.g. in Elk Chess you could specify piece names in the two required Elk types (with N and R move, respectively) as 'Elk (on dark)' and 'Elk (on light)'. This would be of significant benefit to the user, as he can now consciously summon move diagrams for either case. Having only a single entry for the Elk would raise the problem which move Diagram you would have to show, and would not make the user aware that the Elk would move completely differently elsewhere. And I definitely see some benefit to have a piece table with the Smess Diagram that would have a number of Ninnies, called 'Ninny (on e1,e4,e5,e8)', 'Ninny (on c4,c5,g4,g5)' etc., so he could summon all possible move diagrams for a Ninny. The only disadvantage I see is that the existing morph parameter could only specify which Ninny version is needed on a given square if all these versions had different piece ID, which then reflects on game notation.

[Edit] The latter can be solved by introduction of a new parameter localVersion, which does for the preceding group of piece types with the same ID what morph does for the single preceding type. Except that the type you would change to on each square would not be specified by the piece ID (which would be the same for each type in the group), but by letters a-z implicitly assigned to contiguous types with the same ID in table order. That would only allow changes to types within the group. Which is exactly what you need to implement location-dependent moving; in fact the localVersion parameter can be considered the definition of the square properties. If a promotion to a type outside the group is required, a normal morph parameter (indicating the types by piece ID) can still follow, overruling the type change specified in localVersion for all members of the group, while the localVersion of the group to which the piece changes would determine what (micro-)type with that ID we should change to.