Players' ready status when AutoReady is enabled is not always accurate on host's side.

[11EJDE11]

This has been mentioned on Discord a few times as of late.

In my experience:
It can occur without having started a game.
It's just the host that shows the statuses incorrectly. Non hosts it is correct.
IIRC, this issue used to crop up even prior to the large client update, just less frequently.

I've done some analysis and can replicate the problem if the host quickly goes from map > null map > map. I think this is what's happening:

When a map change happens, the host queues a Game Options (GO) message to be sent to non-hosts with the new map. If the map is null then the host also resets the ready statuses.

Because the host changed the map quickly, the queue eliminates the first GO message (containing the null map) and only sends the second (containing the valid map).

This results in LastMapChangeWasInvalid not being set to True for non-hosts as the only message they received indicated a valid map. The result of which is they won't send their ready status to the host (who as mentioned, has already reset the ready statuses).

I'm not sure how best to fix. RequestReadyStatus with every map change?

There was a commit that modified LastMapChangeWasInvalid last month.
I don't really think that that is to blame. I just think this issue is cropping up more because the client is sending null maps more often (searching for a map with gibberish used to hold the last map, but with recent updates it changes it to null).

[SadPencil]

If the map is null then the host also resets the ready statuses.

Not sure, but whether it would help if the host does not reset the ready status? For a null map, the client only prevents the host launching the game, without clearing these statuses.