I understand what you want, and I see why you would think semaphores would not help you. But actually, ten separate semaphores could act as ten separate variables to help you know which locations are “used”. I have no idea if that’s what @kevinb meant or not. He may say, “Um, yes that’s exactly what I meant.”
I’m sure your own approach could work, (although your method might have difficulties if the window creation process is performed by asynchronous macros, which you didn’t clarify) but for the fun of it I want to talk about how you could use ten semaphores to protect ten screen locations. In my mind, a semaphore is to protect a shared resource, which could be a mouse, or a global variable, or a tenth of the screen’s real estate. Assuming you have ten regions on the screen (perhaps an array of 5 x 2 window locations?)
You didn’t mention how you are creating windows, but I don’t think it matters for this solution, as long as your windows are not running asynchronously. When you want to create a window, you would need to check which location is free, by testing the semaphores, something like this: (using ten nested blocks of code)
Notice that you would have ten nested Try Blocks. Each block is responsible for checking a uniquely named semaphore (with a timeout of 1/100 seconds, and no checkboxes checked), and if that check fails (because a window in that position is busy) then it runs the otherwise clause to test the next window location. Eventually it finds a semaphore that isn’t locked and creates a window in the location reserved by that semaphore. The trick to all this occurs at the end of this macro, because you can’t have the macro terminate, or else the semaphore automatically unlocks and subsequent tests will think the location is free. So you must have something at the end of your window-creation macro that never terminates, perhaps this: (make sure the flag Reduce CPU usage is turned on for this action:)
The upside to this approach is that when the (synchronous) window closes, the macro will terminate, automatically freeing up the semaphore that was locking it in place. For this to work, I’m assuming that your window is not running asynchronously, (which you didn’t clarify) because this method uses the fact that the window’s own closing continues the macro that created it, which then closes the macro and unlocks the semaphore.
The downside to this method is that if you ever “terminate all macros” the semaphores will be reset and you will need to close all the windows manually, because the locked semaphores were what reserved the screen locations. But if you do it this way, the macro itself (as long as you execute it asynchronously!!) will lock one of ten screen regions because it locks a semaphore corresponding to the location that it chose.
P.S. If all ten locations are used (all ten semaphores are locked) you will have to handle that case in the final Try statement. Perhaps make a beep sound? Or just place the new window on a random screen location, which is what I would do.
P.S. I didn’t actually test this code. I just happen to have a fair understanding of how semaphores work. So if there’s something wrong above, I’ll help fix it.
P.S. You don’t have to use my approach. I just enjoy promoting semaphores. This is an interesting case study showing how they can be useful. I think I would use this solution to solve your problem, because in my mind it’s a really clean solution, not requiring global variables.
No, I wouldn’t pretend either to have given the matter in-depth thought; I simply felt that it might be useful to first establish whether or not the use of semaphores had been ruled out as irrelevant; it was not clear to me at the time whether or not “The challenge I have is that the macro can run multiple instances” referred to something that was intended behaviour. Carry on… 
