Pieces can already be dropped from the holdings. The possible drop squares are just not highlighted. This seemed pointless, as you can drop on every empty square, and it is already easy enough to see whether a square is empty without displaying a marker in it. A flaw is that you can always do that, even when you have holdingsType=1 for collecting possible promotion choices. But since the AI never drops anyway, and the user can play any illegal move anyway, I never considered this a problem.

Of course when the AI would be able to drop pieces from the holdings, it would be important to indicate in some way whether it is allowed to do that, and where. In my mind I have reserved the @ atom for that in XBetza. Which then should attach alternative meanings to the modifier prefixes and range suffix. Like a range N meaning you can drop only on the first N ranks, a j that you cannot drop on the backrank, an f that you can have only 1 per file. It would not be really difficult to implement this. Just a bit tedious.

Making intelligent drops would be much harder, though. There could be dedicated code for generating drop moves, and adding those to the move list. Testing whether a dropped piece could capture something on a tentative drop square would not be super-expensive. It would be much harder to figure out whether that capture actually is a threat; the attacked piece could be worth less, and be protected. But to know the latter you would have to generate all moves of the opponent after you performed the capture, to see if there is a recapture amongst those. That would make considering a drop very expensive.

There could be an approximate shortcut, though. We could generate opponent moves once before generating drops with a slight twist in the move generator, where it swaps the meaning of XBetza c and d, and then marks the targets of friendly capture as being protected. Instead of doing that only after a just-dropped piece has captured that target, for every drop separately. Then we could consider protected lower-valued pieces safe (also not always true, if there already are attackers), and only try drops that attack higher-valued pieces or unprotected ones.

We could even select more tightly by not trying drops on unsafe squares; the opponent move generation that marked protected pieces could also mark empty squares as being attacked, with the value of the lowest-valued piece that attacks it. Dropping an equal or higher-valued piece on such a square would just sacrifice it. (Which could of course still be good, because you might lure the capturer away from an important defensive location, but with little depth remaining punishing that would be beyond the horizon. Rejecting drops from unnecessary distant safe squares for sliders might be more difficult.

Anyway, at a remaining depth of 2 or 3 ply we could try the subset of drops that passes this filtering, and for both these depths search the reply to a depth of 1 ply (+QS). Only at a remaing depth of 4 ply all drops would be searched, still with a 1-ply reply, and only at 5 ply we would increase the reply depth to 2. If the score resulting from these searches is such that the drop becomes the best move, the depth reduction would be revoked, and the drop would be re-searched to the nominal depth (1 ply less than the remaining depth at the level it was played).