Предположительно исхожу из того, что имелся таки в виду COMEX.doClose, а не COMEX.doStop
Далее, написанное Вами не возможно, если приоритет потоков ожидания выше, чем у основного потока.
Кажется, он у нас THREAD_PRIORITY_HIGHEST
Аналогично, и в случае "а если оба" -- так не бывает. Если мы делаем SetEvent из основного потока, то потоки ожидания именно ожидают. Что означает отсутствие событий приема. И следующие за SetEvent коды будут исполняться только после полного и безусловного завершения потока (приоритет!)

Однако соглашусь, обрабатывать события приема, при установленном сигнале останова - неправильно.
В этом случае "жульство" не катит, надо делать честные массивы. В смысле - не настолько это утяжеляет коды, чтобы ради этого бодаться.
Ну тогда вот он код, без "жульства".
(файл заменен - см. ниже)

Netspirit, я специально не изучал пока вопросы возможного "кольцевания".
Не потому, что я против этого. А потому, чтобы не путаться.
Можно еще и обработку ошибок приклеить (всякие там ParityEroor, FrameError, и т.п.).
Можно еще вспомнить про Ваш Synchronize, DeferredEvent от nesco - и начать бурно протестовать против "индуизма" кодинга (Вы используете AM_SYNC_METHOD, nesco - WM_DEFERREDEVENT, а Кладов - CM_EXECPROC)

Можно все это обсуждать (да и находить адекватные решения), но не все сразу. А то дурдом получится