I still maintain that race conditions cannot occur in a program with a single event loop because the program is implicitly serialized on the event loop itself.

I agree that of course one event handler cannot interrupt another. However, I'm not sure what definition of "race condition" you're using here, in my book this is indeed a race condition, see e.g. Race condition - the definition is broad enough that it certainly applies here. (I'd even argue that event loops are a form of cooperative multitasking, so even the "shared resource accessed from more than one thread" definition applies.) But even if the quibble is about the terminology used, the bug still exists.

... it is not a result of undefined timing. It is very well defined: an attempt is made to use $TX some time later, even if the I/O required to initialize $TX is still pending.

Sorry, I don't understand what you mean by "undefined timing" compared to the sentence following it. (Replace the sleep 5; with sleep rand 10; and the bug still exists.)

I am most familiar with writing Tk callbacks where getting back to the event loop quickly is very important, but Tk ensures that all initialization is complete before the first user callback runs. The error you have found occurs when the event loop is started but some resource used in a callback has not yet been fully initialized.

I have to nitpick here that the error is independent of whether the event loop is running or not* - the error is that the timer is started too soon (or that it fires too soon, however you want to look at it). The model you describe of "set everything up before the event loop starts" doesn't work in network servers for example; resources like client connections, timers associated with those connections, etc. come and go, and in most cases can't be initialized before the event loop starts, and instead have to be dynamically allocated and deallocated.

* Update: To clarify: of course nothing can happen if the event loop isn't running; the rest of the paragraph above hopefully makes clear what I meant to say.

If initializing a connection requires the event loop to run, things get more interesting and you must track the "initialization pending" state somewhere and either drop or requeue timer events until the connection is ready. So the "idle state" for the connection includes a "connected" flag that must remain clear until the connection is actually established. ... and so the pristine model starts to get hairy when put into practice ...

That's one possible solution, but I guess I would also describe it as "hairy". Again, I already showed another that solves the issue, IMO cleanly.