I checked out the UCIed engine. Thanks for doing that! Also your video series is awesome!! I never thought to do incremental building like that. Now that you have demonstrated it so well it seems extremely logical and intuitive. Okay, now some (meaningless) ramblings. Someone that uses C# should at least take a look at Beef and give an opinion or even make a video or two on it. https://www.beeflang.org/. About UCI, I don't get it. It is possible to have 500 ply games and over 1000 ply is not impossible. I heard it takes negligible time to read in and make all those moves.
Question, is the engine expected to unwind all previous moves or just remove the last move and play it? 
If the former then why does not UCI just send a fen instead? 
When I was looking for Beef language I stumbled upon Beef chess engine. Here is a quote. "Beef implements many features found in popular modern engines, built around an original legal-move-only move generation scheme which aims to make search as fast as possible — using this design, the startpos perft speed at one point reached 385 mnps (1 CPU, no hash)! Therefore, Beef mainly hopes to achieve its playing strength from search speed." 385 mnps? On a single thread (implied)? 
When I first started my engine Bricabrac my idea was to do legal move generation with a score by using a one ply pseudo legal search with Qsearch. Now assume 10 pseudo legal moves for three ply, 1000 Qsearch (ignoring beta cuts for sake of argument) need to be done. But in what is proposed 10 + 100 + 1000 only 1110 Qsearch are done. The extra price seems trivial to having a scored list of legal moves. And the benefits of better move ordering should result in less Qsearches, anyway? It was very slow. Did I do it wrong? Or, what am I not understanding?
One last question. Has anyone tried Qsearch with a depth of 1 (or maybe 2) so that it is like regular search except captures (promotions also) do not decrement the search depth?