Well, as a compromise I introduced a parameter fileOffset (default value 0), which determines how much the normal file labeling is shifted to the right (white POV). Where the alphabet is treated as a cyclic set a-w. This means that for fileOffset=1 the left edge gets labeled 'w', and the right edge just gets the next character in the normal sequence (so 'i' for Brouhaha. This was easy to do, and offers at least some improvement for the rare case one would want this.
This would not allow pasting of Game-Courier notation into the Diagram for Brouhaha (assuming the preset there uses the labels x and y), as GC always mentions the square of origin, and the Diagram would not recognize those labels. But I guess GC notation would not be accepted anyway, as it has a space between piece ID and the coordinate move. (This could probably be solved by making the parser ignore all strings of length 1, though, as the piece ID is redundant.) But relatively simple pre-processing of a GC game with a text editor (globally replacing 'y' -> 'i' and ' x' -> ' w') could solve that.
For Omega Chess the wizard squares would become w0, w11, k0 and k11. As the Wizards starting there are also color bound these are not very likely to appear in game notation, unless you would actually move something to those.
Well, as a compromise I introduced a parameter fileOffset (default value 0), which determines how much the normal file labeling is shifted to the right (white POV). Where the alphabet is treated as a cyclic set a-w. This means that for fileOffset=1 the left edge gets labeled 'w', and the right edge just gets the next character in the normal sequence (so 'i' for Brouhaha. This was easy to do, and offers at least some improvement for the rare case one would want this.
This would not allow pasting of Game-Courier notation into the Diagram for Brouhaha (assuming the preset there uses the labels x and y), as GC always mentions the square of origin, and the Diagram would not recognize those labels. But I guess GC notation would not be accepted anyway, as it has a space between piece ID and the coordinate move. (This could probably be solved by making the parser ignore all strings of length 1, though, as the piece ID is redundant.) But relatively simple pre-processing of a GC game with a text editor (globally replacing 'y' -> 'i' and ' x' -> ' w') could solve that.
For Omega Chess the wizard squares would become w0, w11, k0 and k11. As the Wizards starting there are also color bound these are not very likely to appear in game notation, unless you would actually move something to those.