Correct; but it is not the leaving/joining in isolation but also because the game cluster must announce every pilot in local channels (through admin messages that all clients pick up and process but do not display) even if the client of that pilot has not joined that local channel.
A practical example: You are jumping from A to B.
In normal chat the game cluster would call the chat cluster and revoke your access to local A and grant you access to local B. The chat cluster would in response kick you from local A and notify you and all clients in local A. It would then wait for your client to connect to local B and then announce you in local B. For large channels you would not get the full member list and any member list updates might be batched and/or delayed. All very minimal and moderately time critical; very chill.
In EVE chat the game cluster calls the chat cluster, revokes your access to local A, grants you access to local B and then through admin messages immediately announces you having left local A and joined local B. The chat cluster kicks you from local A and notifies your client and other clients in local A. It then waits for your client to connect to local B and then announces you in local B (again; these action/messages may happen in various order since this is a distributed system, but there is always double notification). For large channels you get the full member list when you join and any member list changes are broadcasted immediately. Care must be taken in heavy traffic channels to ensure that you get all individual changes compared to the full member list set you received at the beginning; if the list is snapshotted at time X then you must receive all individual updates at X+ even if you haven’t received the full list yet (you might not have received the list because it takes time to transmit that large list and process it compared to the smaller individual notifications).
Recently we have been looking at the performance of ejabberd, e.g. how it caches data and performance optimizing ejabberd code, and have been deploying such improvements regularly.
Today at downtime (16 Jan) we deployed a rewrite of this snapshotting and transmitting of the initial full member list because the previous implementation was causing issues (including blocking of subsequent actions).