Well, what programmers would have to specify for configuring the Diagram, and what users will finally get to see as a result of that, are completely independent issues. And I am usually a lot less considerate towards programmers than towards users. It is also worthwhile to have a unified method for specifying things, rather than completely different methods for each feature. Irregular promotion zones are already specified in the I.D. through a FEN-like board image, not through a case-label-like list of square coordinates.
I have not proposed anything regarding the specification of irregular promotion zones. My proposal was for how to specify the powers of a piece whose powers of movement are location-dependent. While you might try to simulate that with promotion zones, it is not the same thing, and doing it this way would likely require more overhead and be more confusing to someone looking at it to understand how a piece moves.
I do not see any conflict between making things easier for the programmer and easier to understand for the visitor. What I proposed would be both. Wildcards (or even regular expressions) are no harder to understand than Betza code, and they are both better known than Betza code. Using them in a first-come-first-used manner like cases in a switch statement would allow for a compact presentation of how a piece moves in a manner that should be hardly any more difficult to understand than using Betza code to define how a piece moves.
I have not proposed anything regarding the specification of irregular promotion zones. My proposal was for how to specify the powers of a piece whose powers of movement are location-dependent. While you might try to simulate that with promotion zones, it is not the same thing, and doing it this way would likely require more overhead and be more confusing to someone looking at it to understand how a piece moves.
I do not see any conflict between making things easier for the programmer and easier to understand for the visitor. What I proposed would be both. Wildcards (or even regular expressions) are no harder to understand than Betza code, and they are both better known than Betza code. Using them in a first-come-first-used manner like cases in a switch statement would allow for a compact presentation of how a piece moves in a manner that should be hardly any more difficult to understand than using Betza code to define how a piece moves.