Fairy-Max would have no problem with some of these. Asymmetry is no problem per se, as the move in every direction has to be defined separately.Long-range leapers (bison) is also no problem; any board step is possible on 8x8 (a large lateral step could limit board width, to prevent the piece from jumping over the guard band, and wrapping around the side edges of the board, but 16-stepSize is still possible). Nightriders could lead to some instability, if the search encounters positions where mutual perpetual check is possible. (This means the program would occasionally hang, and lose on time.) I am not sure this is even possible in theory when there is only a single Nightrider present.

As to promotion: Fairy-Max is programmed to promote pieces number 1 and 2 when they reach last rank. It does not matter how these move. If that is not enough, a simple change in the code could make a different number of pieces promote. It would be a bit tricky to make them all promote into different types (but doable). It should hardly matter for the value of a piece to what exactly it promotes, however. Promoting to a piece of approximately the right value should be enough.

Bent riders is currently not possible, as are pieces with a minimum range. They are basically the same thing. It should be possible to patch the code to do those, though. The current system is based on toggling a given set of bits in the initial move step & rights to get secondary step & rights. For non-hoppers this happens after every step, but I just made a change to allow suppression of that for the first 1, 2 or 3 steps, to do the limited-range sliders. After that (as the range counter gets negative) it would toggle every step again. But the code can be trivially changed to only toggle when the counter is zero. This one-time toggle could then switch a primary step with neither capture nor non-capture rights after a certain number of steps to a secondary step with rights for both capture and non-capture. Or it could change the direction of the step. This patch would lose the possibility to do Crooked Bishop or Mao-Rider and such. (But who cares?)

Piece drops are out of the question. For those it would be easier to modify a Shogi program. I would think that also holds for 'swap pieces'. They would need move generation that does not fit at all in Fairy-Max' table-driven system of looping over directions and distance for every piece. You would have to loop over the board in stead, looking for friendly pieces, and to perform the move the occupant of the target square, which normally would be captured, would have to be moved back to the from square. (OK, perhaps this part can be made standard for 'capturing' own pieces.) 'Rifle Chess' pieces would also require a different MakeMove and UndoMove procedure, which now consists of clearing away the captured piece (which for e.p. capture could be somewhere else), clearing the from-square, and putting the moved piece on the target square (possibly promote it there). And for UndoMove clear the target square, put the original piece on the from-square, and put back the captured piece. I guess that when 'shooting' a piece, you would have to skip the second and third part of the MakeMove, based on some new (or redefined) move-rights flag. Or fool it by forcing the target square used during MakeMove to become the from-Square, so that it becomes sort of an e.p. null-move. This might be doable, after all. The challenge is how to preserve the info that this has to be done if the move is not generated from scratch, but the best move of a previous iteration (possibly passed through the hash table).

Capturing mid-move also seems hard. Perhaps this can be done by changing the hopper code (removing the platform, and only allow hops if it is an enemy. If you can do double captures this way, it requires even more code changes (to remember the secondary victim, but not impossible).

So I guess most of this can be done by making dedicated versions by modest patching. But it can't be done all at the same time. (But this is probably not really needed; as long as you don't want to implement complete games.)