Это наподобие этого?

Да, по тому же принципу нужно воспользоваться сообщением LVM_GETITEMRECT.

Но есть ещё одно затруднение, которое я не представляю как обойти — щелчок по пункту контекстного меню самого рабочего стола или любого его элемента (значка) определяется как щелчок по рабочему столу.

Контекстное меню- это окно класса #32768.

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

Как определить вид курсора я нашёл: с помощью встроенной переменной A_Cursor. О курсоре я подумал, т.к. в режиме открытия элементов в Проводнике одним щелчком, курсор при наведении на элемент принимает вид указующего перста. Но я забыл про двухщелчковый режим. Что интересно в однощелчковом щелчок по элементу чаще всего никак не определяется, что в общем-то неплохо. Но это не всегда.
Другое дело, что может не определяться щелчок и по пустому месту, особенно после обновления рабочего стола.

Это наподобие этого? Может быть, хотя я в WinAPI не разбираюсь, как и в самом AHK.

Но есть ещё одно затруднение, которое я не представляю как обойти — щелчок по пункту контекстного меню самого рабочего стола или любого его элемента (значка) определяется как щелчок по рабочему столу.

На всякий случай приведу использованный для проверки простейший код:

~LButton::
WinGetClass, Win_Class, A
WinGetActiveTitle, Win_Title
if (Win_Class = "Progman" and Win_Title = "Program Manager")
{
  MsgBox, %A_Cursor%
}

Конечная цель, которой хотелось бы добиться выглядит очень простой — сворачивания всех окон при щелчке по свободному месту рабочего стола — я, не подумав, так часто, хотя и безуспешно, поступаю, т.к. рабочий стол воспринимается как одно из окон на заднем плане. Также, если мы начали выделять группу значков на рабочем столе было бы разумно, чтобы все окна свернулись и позволиили не вслепую захватить скрытые под ними значки.