Oops, GitHub did a really bad job formatting my reply-via-email. Re-posting:

That's not true -- an AutoConnection decides between direct invocation and queueing based on the emitting thread and the receiver object's thread property alone (if they match, direct. if not, queue). Nothing we did in atomic-co changes this -- a non main thread change made to this control (by looking it up with getControl or in the case of our many shared state multiple thread classes) would queue, not directly invoke. Also queueing is not acceptable here because other parts of Mixxx want this processing to be done immediately (eg so skin processing doesn't have to block while waiting for PlayerManager to get the signal) and this class is designed to be thread safe (locks) because of this.