Gabble makes unique IDs for messages it sends (using libuuid if available, or a good-enough approximation if not), and uses them as the id attribute. This lets a UI reliably match up failing delivery reports to the original message, if it wants to: the message id is exposed as the 'message-token' header field on the Messages interface. We currently expose the 'id' attribute on incoming messages as message-token too, but we should not: we cannot guarantee that the other client produces globally-unique ids. Notably, Google Talk uses incrementing integers...
Fixed in my message-tokens branch.
Sad face, but ++. I wrongly thought that UUIDs were RECOMMENDED as ids, in which case we could have probably got away with the following hack: if the id has the syntax of a UUID, assume that it is one. However, no particular statement is made about the use of UUIDs for id in the RFC (I was confused by the deferred XEP-0201, which says clients MUST use UUIDs for thread IDs).
Fixed in 0.8.6, fixed-but-not-released in 0.9.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.