I just tested it as part of some maintenance, and realized that it is quite broken on Windows 10 (and perhaps 8), since it does not exclude windows that are "cloaked" by the window manager but still have the WS_VISIBLE style, such as apps that are suspended or on a different virtual desktop. Since GroupDeactivate starts at the bottom, I currently have to cycle through 12 "hidden" windows before reaching the first visible one. This makes me think that perhaps no one actually uses this function.
A search of the forums turns up GroupAdd, GroupDelete, GroupTranspose, which defines some functions for dealing with mutable window groups and demonstrates one of them with GroupDeactivate (and GroupActivate).
There are currently only 18 other results, and most of them are incidental and not specifically relating to (or using) GroupDeactivate. I suppose that it is the sort of thing that could be used regularly in personal scripts but rarely in shared scripts.
I intend to change all v1 commands/functions to consider cloaked windows to be hidden (where DetectHiddenWindows applies). Cloaked windows (in general, not just for GroupDeactivate) seem like a big enough issue to risk breaking any scripts that rely on detecting these windows without DetectHiddenWindows On. This excludes most of the problematic windows.
On Windows 10.0.18995, the first two windows to be activated are generally always ahk_class WorkerW. They overlay the ahk_class Progman window and host the Desktop content (whereas that used to be Progman's job). One is owned by Progman and can be retrieved with DllCall("GetLastActivePopup", "ptr", DllCall("GetShellWindow", "ptr"), "ptr"), but is actually disabled (WS_DISABLED) and cannot be activated by mouse (WS_EX_NOACTIVATE). Despite this, it is activated by Win+D (and as a consequence, I cannot immediately use the keyboard to navigate/activate Desktop items). Clicking the Desktop (or attempting to activate ahk_class Progman) activates the other WorkerW window, which is not owned by Progman.
On Windows 7, there appears to be only one WorkerW - the one that isn't disabled - and it is actually hidden on Windows 7, so is already excluded. Oddly enough, Win+D activates this hidden window, but clicking the Desktop activates Progman.
It is trivial to add ahk_class WorkerW to the group so it will not be activated, but it shouldn't be necessary - GroupDeactivate is intended to exclude the Desktop, and does so successfully on older versions of Windows. That being the case, I intend to change v1 to exclude these two WorkerW windows. There are currently many other WorkerW windows on my system, but they are all hidden. I'm not sure whether they are used in any other visible context.
Currently Progman is excluded by the title "Program Manager", which means any other windows with that title are also excluded. GetShellWindow wasn't used originally since it does not exist on Win 9x/NT4. Now because of the WorkerW windows, using GetShellWindow wouldn't be overly helpful.
Windows with WS_EX_TOPMOST (such as the taskbar and Windows 7 start button) are already excluded. Windows with WS_EX_NOACTIVATE or WS_DISABLED could also be excluded easily. That such windows are not already excluded can probably be considered a bug.
Further changes should probably be limited for "backward-compatibility" (or to avoid surprising anyone who expects the current behaviour).
If GroupActivate is kept in v2:
I think that perhaps only windows that appear on the taskbar should be activated, like what happens when you close the active window; so windows with WS_EX_TOOLWINDOW should be excluded unless they have WS_EX_APPWINDOW. That would also efficiently rule out the "WorkerW" windows that always sit at the bottom of the z-order (just above Progman).
If all windows are included in the group or otherwise skipped, GroupDeactivate doesn't do anything. I think perhaps it should activate the Desktop if no eligible window is found, so that the group is actually deactivated. (At the moment, the Desktop/WorkerW window is eligible unless you add it to the group.)
More details