user1@localhost/Tka joins firstname.lastname@example.org with nick user1nick.
Then he sends a presence stanza with extended presence information, even if XEP-45 says 
A client SHOULD NOT presume to generate such information
The stanza could be:
If a MUC service receives such extended presence information from an occupant, it MUST NOT reflect it to other occupants.
However, when ejabberd parses this client stanza, it does not recognize the namespace properly and includes it in the stanza forwarded to other occupants:
Participants receive a stanza with two valid x elements. Each particular implementation uses the first or the second element. For instance, it seems Tkabber and Gajim use the first element, and Psi uses the last.
Problem explained by Teo and Ermine in the ejabberd chatroom.