Наибольшая проблема даже не при дисконекте - в этом случае в очередь сигналы перестают поступать, как выяснено. Проблема, когда соединение есть, а принимающая нить не запущена или по какой-то причине стоит в ожидании. Либо просто медленнее принимает, чем передающая передает. Вот тогда очередь начинает заполняться. И если даже остановить передатчик, то приемник получает всю труху, которая была послана. Избавиться от неё возможности нет.

Проблем с wakeOne/All у меня нет (вообще эти моменты на семафорах сделаны), остановка или просто задержка нити может происходить по внешним причинам. Например, передатчик быстро генерирует управляющие команды, а приёмник посылает их на внешний прибор и считывает с него ответ. А между посылкой команды и получением ответа надо выдерживать паузу 200 мсек. В результате приемник команд обрабатывает команды только каждые 0.2 сек. А передатчик команд может молотить их по чем зря. А потом прибор вдруг не ответил, выдал ошибку - приёмник команды должен выдать сообщение и стать в ожидании действия оператора. И после ответа оператора все команды, которые были посланы передатчиком, уже не нужны, их надо выкинуть - а они сейчас сидят в очереди. Это одна из возможных ситуаций, для которых надо специально предусматривать дополнительные синхронизации, сигналы управления, какие-то ухищрения и т.д. Хотя, если бы была просто приостановка передатчика по заполнению очереди некоей выделенной длины - это можно было бы использовать одинаково со всеми внешними приборами, которые имеют задержку ответа, и которые не имеют. Ну а без очистки очереди просто @$#%&@Q#... Пока пришлось в одном случае вые...ться и сделать специальный цикл выборки очереди в приемнике.

Насчет deleteLater - ИМХО это уже выдумка. Если такой объект послать в очередь обмена между нитями, то вообще не вполне понятно, когда он будет удален даже без очистки очереди. Может грохнуться в момент получения слотом в параллельной нити. Я бы такие объекты в очередь не пихал.

Первый случай решается легко строкой в документации - "нельзя посылать в очередь объекты с deleteLater, кто послал, тот сам дурак". А вот второй случай означает, что авторам плагинов надо будет знать, в каких случаях писать собственный код для очистки очереди, в каких нет. Либо мне надо в родительском классе плагинов как-то предусматривать возможность выборки мусора из очереди (она может не в каждом случае потребоваться), чтобы самим авторам этого не пришлось делать, но тогда надо еще и в документации описать использование всего этого. То есть, отсутствие возможности просто очистить очередь одним вызовом, а вместо этого необходимость множества не совсем тривиальных действий, и порождает негодование. Тем более обоснованное, что внутри Qt это наверняка есть.

Не поможет. Потому как когда в предыдущем примере приемник встанет по ошибке прибора, будет поздно пить боржоми - в очереди уже будет дофига ненужного. А если жестко синхронизировать передатчик и приёмник (напоминаю, что они в разных нитях), то они уже не независмы. Но по задаче подразумевается, что передатчик ничего не знает о приемнике, а приемник о передатчике. Приемники могут быть разные и передатчики разные. Даже обмен идет в QVariant обертках. И даже соединения могут меняться пользователем динамически.