The Interactive Diagram represents pieces by numbers internally, and the piece ID is just a property of the piece, like the name or the move. So there should not be any problem with representing pieces by the same ID. (Not even in notation; the SAN generator and parser are smart enough to disambiguate moves of pieces with the same ID to the same square, even if they are of different type. Drop moves would be a problem, though.) If he wants to select pieces which have the same ID in the table, the user can always change the ID of one of those.
The DirList function for fetching pieces not originally mentioned in the diagram definition would remove originally mentioned pieces for which the image cannot be found in the searched directory, and would then add the images that were found, but not originally mentioned (with a name identical to the name of the image file, and the first letter of that as piece ID, but no move). This adding is done by adding piece lines to the Diagram definition, before parsing the latter to make a Diagram. Since defaulting of the image name to the piece name is only done after parsing, I suppose that predefined pieces without image name can indeed get removed in this process.
There seems to be a problem caused by having multiple Diagrams on one page (in the Comments listing), where a problem in one Diagram (an undefined image name) seems to spill over to other Diagrams. The first thing to do in such a case is always to test whether a Diagram works in isolation, by clicking the View link in the comment.
In principle JavaScript errors can be traced (in FireFox) by hitting the F12 key, and looking in the console. You have to look really hard, though, as loading a CVP page typically produces dozens of errors from JavaScript in the ads. But when I scrolled back far enough I did find a complaint against JavaScript in the betza.js file, for your forelast Diagram in this topic thread.
As to a limit on the number of piece types: you will probably get in trouble for 250 or more, since holes in the board are represented by 250. Originally there could be 511 types, as the 512 bit is used to indicate the piece has moved. (So one could say there are two times 511 types, the virgin types and the 'has moved' types, and moving automatially promotes to the latter.) Later I decided that 250 would probably be enough, and the 512 and 256 bits in promotion codes now are used to indicate explosions.
The 1024 bit is used to indicate color. Higher bits in the codes in the board array are used as markers for the square, e.g. to indicate whether a destination corresponds to a castling or e.p. capture, or is under attack by an enemy (so that moves of royal pieces to it should be indicated y a gray cross). This is used by the old move-entry system; the newClick routine in betzaNew.js would not need it. (But even there move diagrams are still displayed with the aid of the old highlighting routines, as these also must indicate invalid moves, like captures to an empty square, something that newClick cannot do yet.)
There are enough bits available there, so in principle everything there could be shifted to higher bits, making more low-order bits available for representing the piece type. But that would require changing the code in many, many places. And not only that, but also all custom scripts added to individual Diagrams all over the site, which now rely on 1024 representing color and 512 representing virginity. So it seems this would only be feasible by creating a new fork of the Diagram script, incompatible with all existing Diagrams. The use of which would interfere with Diagrams on the same page using the old script, as they contain functions with the same name, which would redefine each other. So I think prospects for an expansion are pretty bleak.
The ID wasn't really designed for the purpose of implementing Play-Test Applets. If you really want to provide an unlimited choice of piece icons, I guess the easiest way to program this is similar to the way the new Play-Test Applet I am developing now handles mutiple types with identical icon (through a duplicate button): allow the user to add a number of 'very exotic' icons he needs to the Diagram's table, selecting those from some other table that you embed yourself in the page (E.g. showing white icons only, without name or move, and let a click on those add them behind the King, which then would also reveal the image name.) Perhaps all automatically added pieces should go into this table.
The Interactive Diagram represents pieces by numbers internally, and the piece ID is just a property of the piece, like the name or the move. So there should not be any problem with representing pieces by the same ID. (Not even in notation; the SAN generator and parser are smart enough to disambiguate moves of pieces with the same ID to the same square, even if they are of different type. Drop moves would be a problem, though.) If he wants to select pieces which have the same ID in the table, the user can always change the ID of one of those.
The DirList function for fetching pieces not originally mentioned in the diagram definition would remove originally mentioned pieces for which the image cannot be found in the searched directory, and would then add the images that were found, but not originally mentioned (with a name identical to the name of the image file, and the first letter of that as piece ID, but no move). This adding is done by adding piece lines to the Diagram definition, before parsing the latter to make a Diagram. Since defaulting of the image name to the piece name is only done after parsing, I suppose that predefined pieces without image name can indeed get removed in this process.
There seems to be a problem caused by having multiple Diagrams on one page (in the Comments listing), where a problem in one Diagram (an undefined image name) seems to spill over to other Diagrams. The first thing to do in such a case is always to test whether a Diagram works in isolation, by clicking the View link in the comment.
In principle JavaScript errors can be traced (in FireFox) by hitting the F12 key, and looking in the console. You have to look really hard, though, as loading a CVP page typically produces dozens of errors from JavaScript in the ads. But when I scrolled back far enough I did find a complaint against JavaScript in the betza.js file, for your forelast Diagram in this topic thread.
As to a limit on the number of piece types: you will probably get in trouble for 250 or more, since holes in the board are represented by 250. Originally there could be 511 types, as the 512 bit is used to indicate the piece has moved. (So one could say there are two times 511 types, the virgin types and the 'has moved' types, and moving automatially promotes to the latter.) Later I decided that 250 would probably be enough, and the 512 and 256 bits in promotion codes now are used to indicate explosions.
The 1024 bit is used to indicate color. Higher bits in the codes in the board array are used as markers for the square, e.g. to indicate whether a destination corresponds to a castling or e.p. capture, or is under attack by an enemy (so that moves of royal pieces to it should be indicated y a gray cross). This is used by the old move-entry system; the newClick routine in betzaNew.js would not need it. (But even there move diagrams are still displayed with the aid of the old highlighting routines, as these also must indicate invalid moves, like captures to an empty square, something that newClick cannot do yet.)
There are enough bits available there, so in principle everything there could be shifted to higher bits, making more low-order bits available for representing the piece type. But that would require changing the code in many, many places. And not only that, but also all custom scripts added to individual Diagrams all over the site, which now rely on 1024 representing color and 512 representing virginity. So it seems this would only be feasible by creating a new fork of the Diagram script, incompatible with all existing Diagrams. The use of which would interfere with Diagrams on the same page using the old script, as they contain functions with the same name, which would redefine each other. So I think prospects for an expansion are pretty bleak.
The ID wasn't really designed for the purpose of implementing Play-Test Applets. If you really want to provide an unlimited choice of piece icons, I guess the easiest way to program this is similar to the way the new Play-Test Applet I am developing now handles mutiple types with identical icon (through a duplicate button): allow the user to add a number of 'very exotic' icons he needs to the Diagram's table, selecting those from some other table that you embed yourself in the page (E.g. showing white icons only, without name or move, and let a click on those add them behind the King, which then would also reveal the image name.) Perhaps all automatically added pieces should go into this table.