H.G.M.: '... how much effort one should put into upkeeping a unified approach ...'
Why not, if the effort isn't too big? So let's try out some ideas.
H.G.M.: uses: 'Ke1-i1&Rj1-h1'
Maybe I am too traditional, but I would like to have an encoding startig with 'O'. Here I would suggest to write 'O-i-h' using the first column letter for an untypical King's target square and the second one for an untypical (not inner neighbored) Rook's target square.
H.G.M.: '... but simply as FROM and TO square ...'
Appending a letter (I would prefer the involved Rook's/piece's source column letter) is only a partial solution, because this forces the GUI to somehow generate the input gesture squares, which demands, that its programmer has anticipated this (what is not necessarily the case at a new variant). But, because the problem of two unique squares representing this move exists nevertheless, it would be covering more, to use those square coordinates also for to communicate the move.
Nevertheless here again is an encoding problem, when a free castling would also allow to place the Rook on different selectable squares. Thus I still have problems with such types of castlings.
My understanding of a GUI is, that it has not to know much about chess. It has to ask for all the possible moves, have the user make a selection e.g. by clicking at two squares, and to communicate this choice to the engine, using the move code it has sent before by request.