PS: Rustic is not "really" a UCI or Winboard engine. Internally, it uses collections of structs.
uci's "position fen <string>" is basically the same as "setboard <fen>"
uci's "info" output is the same as xboard's "thinking output"
same for the "." command: it requests information that uci already sends by default (time, nodes, currmove, etc....)
So, internally the engine uses its own struct stuff, and the uci/xboard communication modules transform incoming commands to something the engine understands, and outgoing data into either uci or xboard. Both protocols are built on top of the same infrastructure. Nothing within the engine except the main engine thread itself is aware if it is running the UCI or XBoard modules; and the main engine thread only uses this information to buffer the incoming search stats until the GUI asks for it with the Dot-command. (Maybe I'll even take that out of the engine thread an move the buffering to the XBoard module: so the engine does send the incoming stats to be printed, but the comm module can catch those and buffer/update them until the Dot comes in.)
Actually, if I would take the time to implement disconnecting and reconnecting the comm threads, and have a GUI that supports it, I could have the engine switch from UCI to XBoard in the middle of a search if I'd want to... but fortunately no GUI supports insane stuff like that, so I don't get tempted to try it
