When i do multiple traces back to back (i.e. 3 people join the room at the same time), the traces aren't returned in the order they were qued. I.E. trace a, trace b, trace c - trace c returns first, before trace a and trace b. Thus when I do a check before immediately output to make sure that a of trace is actually a of A@1.2.3.4, 3 out 7 times they aren't matching, due to the traces not being return in the order they were performed.

So, should I just first save the trace result to the table to ensure that it gets saved (correctly), and then read it back from the table?

I can extract the name from the trace to ensure that it's being first saved correctly, then check for originating name of trace matches result name of trace. If they don't match, at least it was save correctly, but not displayed if they don't match.

Are you talking about a custom tracing or the /trace command?
In case of the latter (and on unreal ircd), $4 of raw 200 is always the traced nick.
Anyway, you might script a default queue for your nicks-to-trace (hash table, string of tokens in a variable,...), firing the next trace at the moment the last has finished (on raw 205 or 402 if it's about /trace)

Yep, I do /trace on join and extract/save data from $4 to a table. Forexample when 3 people join the room at the same time and 3 /traces are executed back to back, the order that the traces come back might not be the same as they were executed, as /trace responce time can vary.

What I did to prevent the wrong trace for showing up for the wrong person joint he room, was to immedately save the /trace data as it returns. Then call the trace data from the table with the person's name, which is the item in the table. So far it seems to have fixed the problem.