So…floating windows. Why don't they like to be closed?! (Specifically, I'm in iZotope RX.) I've gotten…close. 
Update: Solved! I managed to get UI Browser working, and yes - the button number to close each floating window is different. However, this works:
click (first button of window 1 whose description is "close button")
(You can also substitute the window number with the name of the window; this lets you close floating windows that are not in focus.)
I don't have the time (nor expertise!) to look at your macros, but generally, I've found the only reliable way to close a floating window is to make sure you name it in the <body> tag, then you can close it with an Execute JavaScript in Custom Prompt action.
In the custom HTML prompt:
<body data-kmwindowid="thatonewindow" ... >
In the Execute JavaScript in Custom Prompt action:
Window ID: thatonewindow
Execute text script • Ignore results
window.KeyboardMaestro.Cancel()
Whether this will work with how you're doing things, I don't know. But if you can name each window uniquely, then you should be able to close them later with the above action. Hope that helps, not sure it will (my custom HTML prompt is trivial and tame compared to what you've described, I think).
-rob.
Thank you for sharing your response. That's a cool way to handle those windows, cheers. Peter also had a way to do this in KM by grabbing the windows ID, and this allowed you to do things like minimize the window.
In my post, I was referring to floating windows from third-party applications. @noisneil provided scripting to find and focus them - but closing them is challenging because button #1 doesn't do it, and without UI Browser, I can see what does. I also think it's different for each window (in RX); for example, button #2 closes one of the windows, but not the others. 
Ah, OK, that makes sense. Floating windows in third party windows could definitely be challenging. (And there is no standard, so almost anything could close them.)
Hope you find a fix!
-rob.
I do! Updated in the first post.