This generally looks good, and I support publication.

Blockers for advancement:

* I don't think you can use the internal TLD here. That's a free-for-all on private networks, and in cases where a XID is confused with a JID (since they share the same syntax) it could end up resolving to an actual XMPP server. Does the syntax for a XID have to match that of a jid? If so, I'd suggest that the XSF creates a xid.xmpp.org domain for this purpose, with zero'd SRV records.
* The challenge protocol is trivially MITMable. I suggest including the source jid within the signed payload, and possibly signing the challenge with the source XID too. This would mean that the challenge was mutual, and mutually verifiable, though not end-to-end of course.

Four notes:

* I would strongly consider adding an expiry to the XID publication.
* I would also explicitly allow multiple XIDs - perhaps this is in place already, I didn't notice it (but haven't exhaustively searched).
* I would also highly recommend examining PQ options (presumably KEM or HPKI based) and also threshold cryptography might be interesting as well.
* By way of another approach worth examining, I'd suggest looking at Philip Hallam-Baker's Mesh and its id service, callsigns: https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-callsign-01Dave.