Beware that "nightmare to program in software" and "nightmare to play" could be pretty much the same thing.
But I am not sure that this isn't an exaggeration, as most features of this game already can be handled by the Interactive Diagram without custom scripting. What cannot be done is often very similar to what is already done; e.g. the ID does support spells, just not two different spells at the same time. It doesn't support a Friend, but this is similar to move induction. Borrowing of special powers adds some complexity to this piece, but Rifle and withdrawer capture are just moves; I would not describe those as "special powers". (Which makes it all the more strange you exclude borrowing of e.p. capture...)
Multiple spells might be a nice feature to have anyway. The ID implements spells by tracking the location of pieces (maximally two of each type, but in cases where there are more you can articicially split the type in two identical types), so that you don't have to scan the entire board if you want to know where pieces of a certain type are. For its normal operation this isn't needed, so it is only done when spells are defined, to easily locate the sources of the spell. This switches on tracking of all piece types; that you have to specify a piece number in the parameter trackPieces=N is only to indicate which pieces cast the spell. When multiple spells are to be supported, it obviously should become possible to specify the type of spell on a per-piece basis, and this would make the trackPieces parameter redundant; tracking could automatically be switched on if any of the participating pieces casts a spell.
The way the spells work now is that before starting move generation in a given position, it goes through the list of spell-casting pieces, and marks a 'neighbor' board to indicate which squares are in the spell zone of those. The move generator has tests in places where its action could be affected by a spell (such as when it gets to a new piece, testing if that piece is immobilized, and aborting the generation of its moves when it is), to see if that spell is in force, and if so, whether the square is in its zone by consulting the neighbor board.
For implementing multiple spells there should just be a separate neigbor board for each spell flavor; the move generator would then not have to test whether the spell that would affect its decision at that point is in force, but can directly test the square on the neighborhood for the applicable spell. So for the origin square it would test the 'freeze' neighbor board to see if any moves must be generated for the piece at all, on a square reached by a slider the 'brake' neighbor board, to see if sliding can continue, etc.
When going through the spell-casting pieces it would then mark the spell zone for each of those in the board belonging to the spell that piece casts. Whether each piece should be allowed to have a different spell zone as well as a different spell, and whether a single piece should be allowed to cast an arbitrary combination of spells is a good question. For this game that would not be needed, provided Hia power would be on the spell menu as what currently is 'brake' in combination with 'slow'. So if we defer that to later date, the modification required for allowing different spells by different types, all with the same zone, in one variant, is really quite minimal.
That leaves the Friend. This would require a special algorithm, because you apparently allow moves of one piece to be relayed from Friend to Friend through moves borrowed from another piece. (I am not sure whether this was the intention of the original definition; you already get relay chains if piece moves can only be relayed through moves of that piece type, and this would be a lot easier to program.) The way I would handle it is first generate all the moves of the other pieces, but record for each Friend which pieces had moves that were hitting it. This could actually be handled by replacing all Friends by some innocent enemy piece, so that the moves hitting it appear as captures of those in the move list. Afterwards you could then run through the move list to collect all moves that were capturing to the Friend's location, to build the list of its protectors, and delete the moves from the move list.
The next step would go through all Friends, and for each of those generate the moves of all pieces that were hitting it. Still under conditions where the Friends are replaced by enemies. If amongst the moves this adds there are captures to the Friend squares, you would merge the list of attackers of the protected Friend with that of its protector to get the new list of the hit Friend. And you would remember if this really added any new pieces. If any of the Friends would acquire new moves because of that, you would delete all the Friend moves from the move list, and repeat the process with the new capabilities.
If you no more changes to the lists of mimicked pieces occur, you finally delete all the moves to the Friend squares from the move list, and put the Friends back in their place. If there are not too many piece types (say 30) , the lists of capabilities could conveniently be made as a bitmap, where each bit in an integer represents a piece type, and gets set to 1 of the Friend mimics that piece type. Merging the lists can then be done with bitwise logical operations.
Of course the borrowing of the spell-casting abilities as part of mimicking would require conditional marking of the neighbor boards for those spells by Friends, depending on what they are mimicking. Which must be calculated here during the opponent's turn (as the involved spells are of the type that affect enemies), where it would already have changed compared to how it was before the preceding half-move. So you would have to re-run the opponent move generation, including the Friend chaining, in order to know which Friends cast spells.
I have my doubts whether this 'Recursive Friend' makes a nice game for humans, so I am not really eager to have the ID support it. I am leaning to a simpler version of the Friend, where it only relays the power to mimic a piece through the move of that piece. In that case the move generator, whenever it hits a new Friend, can immediately continue generating moves for that Friend according to the same prescription. That seems more manageable for humans too. We want to avoid the emergence of a new proverb "the Friend is your worst enemy"!
Some remarks on your description:
Can a Friend attacked by a Pawn promote? You don't mention that, but promotion should certainly be considered a special power...
W.r.t. the Squirrel, 'displace' can mean anything, but somewere burried down deep it turns out you actually mean 'swap location with'.
Better explicitly state that the withdrawer capture is optional, and not a mandatory side effect of the move, as this is quite unusual.
The distant rifle captures might be insanely strong. As they can be made from a safe distance there is basically no defense against those other than moving the attacked piece away. But they have good forking power. So the game might degenerate into quickly centralizing the Snipers, and massacring the opponent with it.
Beware that "nightmare to program in software" and "nightmare to play" could be pretty much the same thing.
But I am not sure that this isn't an exaggeration, as most features of this game already can be handled by the Interactive Diagram without custom scripting. What cannot be done is often very similar to what is already done; e.g. the ID does support spells, just not two different spells at the same time. It doesn't support a Friend, but this is similar to move induction. Borrowing of special powers adds some complexity to this piece, but Rifle and withdrawer capture are just moves; I would not describe those as "special powers". (Which makes it all the more strange you exclude borrowing of e.p. capture...)
Multiple spells might be a nice feature to have anyway. The ID implements spells by tracking the location of pieces (maximally two of each type, but in cases where there are more you can articicially split the type in two identical types), so that you don't have to scan the entire board if you want to know where pieces of a certain type are. For its normal operation this isn't needed, so it is only done when spells are defined, to easily locate the sources of the spell. This switches on tracking of all piece types; that you have to specify a piece number in the parameter trackPieces=N is only to indicate which pieces cast the spell. When multiple spells are to be supported, it obviously should become possible to specify the type of spell on a per-piece basis, and this would make the trackPieces parameter redundant; tracking could automatically be switched on if any of the participating pieces casts a spell.
The way the spells work now is that before starting move generation in a given position, it goes through the list of spell-casting pieces, and marks a 'neighbor' board to indicate which squares are in the spell zone of those. The move generator has tests in places where its action could be affected by a spell (such as when it gets to a new piece, testing if that piece is immobilized, and aborting the generation of its moves when it is), to see if that spell is in force, and if so, whether the square is in its zone by consulting the neighbor board.
For implementing multiple spells there should just be a separate neigbor board for each spell flavor; the move generator would then not have to test whether the spell that would affect its decision at that point is in force, but can directly test the square on the neighborhood for the applicable spell. So for the origin square it would test the 'freeze' neighbor board to see if any moves must be generated for the piece at all, on a square reached by a slider the 'brake' neighbor board, to see if sliding can continue, etc.
When going through the spell-casting pieces it would then mark the spell zone for each of those in the board belonging to the spell that piece casts. Whether each piece should be allowed to have a different spell zone as well as a different spell, and whether a single piece should be allowed to cast an arbitrary combination of spells is a good question. For this game that would not be needed, provided Hia power would be on the spell menu as what currently is 'brake' in combination with 'slow'. So if we defer that to later date, the modification required for allowing different spells by different types, all with the same zone, in one variant, is really quite minimal.
That leaves the Friend. This would require a special algorithm, because you apparently allow moves of one piece to be relayed from Friend to Friend through moves borrowed from another piece. (I am not sure whether this was the intention of the original definition; you already get relay chains if piece moves can only be relayed through moves of that piece type, and this would be a lot easier to program.) The way I would handle it is first generate all the moves of the other pieces, but record for each Friend which pieces had moves that were hitting it. This could actually be handled by replacing all Friends by some innocent enemy piece, so that the moves hitting it appear as captures of those in the move list. Afterwards you could then run through the move list to collect all moves that were capturing to the Friend's location, to build the list of its protectors, and delete the moves from the move list.
The next step would go through all Friends, and for each of those generate the moves of all pieces that were hitting it. Still under conditions where the Friends are replaced by enemies. If amongst the moves this adds there are captures to the Friend squares, you would merge the list of attackers of the protected Friend with that of its protector to get the new list of the hit Friend. And you would remember if this really added any new pieces. If any of the Friends would acquire new moves because of that, you would delete all the Friend moves from the move list, and repeat the process with the new capabilities.
If you no more changes to the lists of mimicked pieces occur, you finally delete all the moves to the Friend squares from the move list, and put the Friends back in their place. If there are not too many piece types (say 30) , the lists of capabilities could conveniently be made as a bitmap, where each bit in an integer represents a piece type, and gets set to 1 of the Friend mimics that piece type. Merging the lists can then be done with bitwise logical operations.
Of course the borrowing of the spell-casting abilities as part of mimicking would require conditional marking of the neighbor boards for those spells by Friends, depending on what they are mimicking. Which must be calculated here during the opponent's turn (as the involved spells are of the type that affect enemies), where it would already have changed compared to how it was before the preceding half-move. So you would have to re-run the opponent move generation, including the Friend chaining, in order to know which Friends cast spells.
I have my doubts whether this 'Recursive Friend' makes a nice game for humans, so I am not really eager to have the ID support it. I am leaning to a simpler version of the Friend, where it only relays the power to mimic a piece through the move of that piece. In that case the move generator, whenever it hits a new Friend, can immediately continue generating moves for that Friend according to the same prescription. That seems more manageable for humans too. We want to avoid the emergence of a new proverb "the Friend is your worst enemy"!
Some remarks on your description: