I meant: would it be possible to clear a piece from an occupied square by 'free-dropping' an empty square on top of it (e.g. by entering @-f1).

Yes, that is possible. But there are other ways of removing a piece from a space without moving to it. You can use the empty command, the remove function in an expression, or the notation of moving what's on that space nowhere, such as f1-. In contrast, -f3 would remove the space. See the user guide for details on different types of notation.

And come to think of it: the code that checked the promotion just looks whether the piece at 'dest' after the move is still 'moved'. But what if someone would have really entered the typo R a1-f1; Q-a1;

The ban command allows the programmer to ban certain kinds of moves, so that the main code doesn't have to handle them. If a blanket ban command is used, the allow command can be used to explicitly allow certain kinds of moves. Since the Rook would be on f1, adding a Queen to a1 would be a free drop, and these may be banned without banning promotions. A free drop is a drop from nowhere to an empty space, whereas a promotion is to an occupied space. This is commonly done in most Chess variants with code like this:

ban commands allmoves;
allow moves 1 captures 1 promotions 2;

BTW, some variants allow only promotion of a piece that was lost before, and in those it can make sense to collect the captured pieces in a separate area (without color flip), and move them from there to effect promotion.

See how Grand Chess and Gross Chess handle this. As Greg mentioned, Game Courier keeps track of captured pieces. Although this is normally done automatically, it can also be done in a manner controlled by the code. Data on the captured pieces can be used to control which pieces a Pawn may promote to.

'Locust capture' in general is capturing a piece on a square you are not moving to.

This is handled in the Pawn functions and subroutines because of en passant. Although functions are ideally meant to return a value without changing the position, I had to add a remove function so that the Pawn functions would handle en passant properly.

The problem arises when the capture would be optional.

Each move option has to be distinguished in the notation. If a piece may optionally capture a piece on another space than the one it moves to, it's move might have to be broken into two moves. This could be handled as moving to the space the piece is on, then moving to another space. Or it could be handled by moving directly to its destination and capturing the piece as a second move. Without rule enforcement, the choice of notation wouldn't matter. But with rule enforcement, you should pick one and think about how to program it. The latter has the advantage of not introducing a second regular move. If you did it the first way, you would have to allow regular moves on the second move, and then your main code would have to prevent it whenever it is illegal. Using the latter way, you could allow suicides on the second move, and that might be easier to handle.

In general, much of the code is able to be kept as simple as possible by banning all the types of movement that are never used in a game. For example, players could delete spaces, do rifle captures, or use GAME Code to enter complex moves. But when the programmer bans certain types of input, that reduces what the code has to deal with. So, code for checking the legality of moves comes in the context of assuming that certain types of input are banned. If you want to convert Betza notation to GAME Code functions and subroutines, you might have to assume a context where any type of move is allowed, and that would make programming more complicated.