Speaking as a veteran (just not one of the WINNING kind…but at least a finalist one year long ago)
For my part… the signalR and docker stuff does not bother me TBH.
Full disclosure, I use docker and containers all the time in the day job (and for hobby projects etc), so I’m pretty used to that.
There was at least one competition that used XML and SOAP - don’t know if anybody remembers THAT.
But even with the horror show that is SOAP…it’s OK. The IO channel, whatever it might be , imho, is not really a deal breaker.
Just using file-based I/O definitely feels simpler (for us players), but I’m pretty sure the performance penalty is pretty heavy when you have 100s (or more) of games to run. It also complicates things infra-wise since you now need shared storage of some sort so that all the producers and consumers of these file artifacts can actually talk to each other.
And remember, everybody want to see tournament results NOW NOW NOW or earlier, so doing things that help move in that direction helps us all when it comes to crunch times.
What tripped me up this year was mostly just not realizing the challenge was actually up and running.
I only realized when the “build-a-bot workshop” email went out (thanks for the video link btw, still need to watch!)…and that was , it seems, 2 months after things were already open-ish, going by some historic posts here.
So for myself, I’m 2 months behind, with a lot of “llife and day job” things going on.
As for engine bugs - not sure what to say. That has been, in my experience, par for the course, every year I was able to compete. Like…bugs that sometimes flat out contradicted published rules.
Part of the fun I would say.
If you can identify a bug - maybe create an issue, with lots of details and example game states, on github, and then perhaps also raise a topic here? And link to GH issue?
Even better, raise a PR with a suggested fix?
If I were to raise a peeve…it would be, that in my estimation, C# bots might have a slight advantage, seeing as how the engine is also written in C#. So if they were so inclined, C# bot authors can potentially have an easier time implementing rules (and for example collision checks + resolutions) “correctly”.
So in summary, best advise I can give : abstract your I/O parts away from the “fun” stuff, get the I/O stuff sorted out early, and then you can focus on the “fun” stuff.
And refer to the published engine rules to see how rules are REALLY implemented, don’t trust any published rules 
By the way - is it just me, or does the published rules feel esp thin this year? Just seems to raise more question for me…