This needs investigation.

You can see this by looking at the header for any patch message. 
Interestingly, this does not affect the issue tracker messages.

Oh! msg10061 from this bug also seems to exhibit this symptom and
perhaps this reply will as well.

OK, I have a better idea what's happening.  The second message has a
correct in-reply-to.

Notice this chunk of roundupdb.py:

            if not inreplyto:
                # Default the reply to the first message
                msgs = self.get(nodeid, 'messages')
                # Assume messages are sorted by increasing message
number here
                if msgs[0] != nodeid:
                    inreplyto = messages.get(msgs[0], 'messageid')
                    if inreplyto:
                        writer.addheader('In-Reply-To', inreplyto)

I'm not clear on why it does this.  Why not just not write the header?
Anyway, I've filed http://issues.roundup-tracker.org/issue2550640 and
will follow up when they reply.

PS. trying new policy trick of assigning to the person who's supposed to
chase up, if we're actually waiting-for an outside party.  In this case,
we're waiting for the Roundup Team, but I'm assigning to me as I'm the
one that gets replies on their ticket.

The roundup folks got back to us very quickly.  Turns out it was a bug,
and they've fixed it.  This looks like just a one-liner
http://svn.roundup-tracker.org/viewvc/roundup/roundup/trunk/roundup/roundupdb.py?r1=4464&r2=4463&pathrev=4464
(if you ignore what should have been a darcs replace patch for them), so
maybe we should just fix it on our install.

This was resolved by changing this snippet

-               if msgs[0] != nodeid:
+               if msgs[0] != msgid:
                    inreplyto = messages.get(msgs[0], 'messageid')

You can check issue1799 and issue1799 to confirm this.