Код компонента красив и лаконичен.
Я когда-то долго хуками занимался и хочу лишь отметить несколько вещей.
Во-первых, никаких длительных операций в обработчике хука (здесь в onMouseXXX). Если этого не избежать, то надо разносить хук и onMouseXXX по разным потокам.
Во-вторых, низкоуровневый хук все равно может время от времени слетать и лучше предпринять меры для его переустановки. Для XP это не актуально, а вот выше XP - проблема.
В-третих (к хукам уже не относится), WindowFromPoint не всегда выдает именно окно под курсором. Если стоит задача определить родительское окно верхнего уровня, то проблем нет. Но если нужно найти, скажем, какую-нибудь кнопочку, то может выдать, например, groupbox под ней

Вот это мне и не понравилось, почему я его и не стал добавлять в пакет.

Мне так кажется, что достаточно применить оконный обработчик и передавать ему PostMessage. Но тогда возможны небольшие задержки

Если и для обработчика хука и для нашего PostMessage будет использоваться одна и та же очередь сообщений, то может случиться так что сообщение для хук-обработчика будет поставлено в очередь во время обработки нашего PostMessage (поставленого в очередь во время предыдущего срабатывания хук-обработчика)и Windows просто не дождется когда же мы закончим этот PostMessage обрабатывать и изымем из очереди сообщение для хук-обработчика. Если же использовать разные потоки, то есть шанс что планировщик потоков прервет исполнение долгой операции и передаст управление потоку с хук-обработчиком до того как Windows решит прибить наш хук. Для повышения этого шанса можно еще и приоритет потока с обработчиком хука поднять до критического. Но все равно это не даст 100% гарантии что наш хук будет не тронут. Я дополнительно еще костыль лепил: в начале функции обработчика хука заводил таймер на 1.5 сек, а в конце его прибивал. Если таймер все же срабатывал, это значило что функция до конца не отработала и обработчик таймера переустанавливал хук. У меня стояла задача не просто мониторить события мыши/клавиатуры, но и блокировать их при необходимости. Поэтому функцию-обработчик хука и свой код по обработке я разнести по разным потокам не мог. Однако для хука я все-таки выделял собственный поток, т. к. программа делалась как плагин в виде dll для другой программы и хрен его знает что там в той программе на поток загрузивший мою dll было завязано

В принципе, элемент хука можно запустить из другого потока не лезя в код, а синхронное событие использовать для определения наличия изменения состояния

В принципе да. Но только использовать что-то типа семафоров-мутексов немного накладно: придется какую-то очередь организовывать для пришедших событий. Чисто для мониторинга проще слать PostMessage со всеми данными случившегося события в другой поток, где их и обрабатывать.
------------ Дoбавленo в 11.52:
Хотя вся структура MSLLHOOKSTRUCT в PostMessage не влезет, только самое необходимое
------------ Дoбавленo в 12.17:
С другой стороны кто нам запрещает разбить ее на несколько сообщений

Или передать указатель на нее...

Так она ж не будет жить вечно. Как только обработчик хука завершится, этот указатель может начать в любой момент указывать в небо Так что именно на нее нельзя. А вот если создать ее копию, то на копию можно. Но тут опять очередь из этих копий организовывать.
Да, выше я имел в виду не PostMessage а PostThreadMessage. Хотя тут надо думать что выгоднее - дополнительное окно или дополнительный поток создавать.
А вообще все это начинает походить на забивание гвоздей микроскопом

Да, очень смахивает

Это так экспериментальный вариант, зарисовки на тему