When sending presences the server must send back the presence to the JID, see https://tools.ietf.org/html/rfc6121#section-4.2.2.
Most of the servers are also keeping the initial ID (like M-Link, ejabberd, Prosody) then the client can handle properly the response.
I don't think the fix for ever completely worked. It is based on a presence broadcast that sends a presence update to all subscribed entities, as well as all resources of the same user that are available.
The problem lies in the fact that the presence update was 'recorded' in the client session only after this broadcast was done. When iterating over all client session to find resources that are available, the session from where the update originated, is still reporting the previous presence state (in case of a new session: unavailable).
To me, re-ordering events seem logical, and desirable for other reasons. It makes sense to first store the presence update in the client session, and only then broadcast the update.
With this fix, the test mentioned above now produces:
Thanks, but what do you mean by 'A second presence stanza is received.' ?
I mean (from the clients perspective), this is what I observed:
The fix that was applied earlier improved the reflection of initial presence, but introduced the original problem when reflecting offline presence.
This is being logged on debug: