I made a modified version that does what you're looking for I think.
I included comments to explain what I changed and what's going on in the event sheet.
I'll use "Block" to refer to the green blocks, instead of "Sprite", to stay consistent with my example capx.
(I renamed the object in the capx while I was trying to figure things out.)
I think what was happening in the original capx is that the "While Block is overlapping Block" event was not actually selecting (picking) any blocks.
The reason is that this "While" event was a sub event, attached to a parent event in which you created a new block using "Create object".
After creating a new Block with the "Create object" action, only that new block is selected. When you enter a sub event, it's still only that one Block that's selected.
So, when the sub event tries to check for overlapping Block objects, it is only checking for overlaps among the selected blocks. The problem is there's only one selected block at this point, and it can't overlap itself, so no Blocks meet the overlap condition, and as a result now no Blocks are selected.
From this point on, there are no Blocks selected, so any events acting on Blocks will have no effect.
You can test this by locating the "While" event, and adding the action "Block: Set Scale to 4", which will make any Blocks selected by that overlap condition 4 times bigger. When testing you should still see overlaps, but no Blocks will ever be made bigger, because that event never actually selects any Blocks.
It turns out that handling collisions between two instances of the same type of object, and then acting on one of those instances is a little tricky in Construct.
To get around this, we put the Block object in two different families "fS_overlapA" and "fS_overlapB".
(The "fS_" is just my shorthand for "Family" of "Sprite" type objects.)
A family keeps its own separate list of selected (picked) objects.
So the event
Block overlapping Block
can now be rewritten
Pick fS_overlapA by UID (use current Block's UID)
When fS_overlapA overlapping fS_overlapB
This guarantees that one of the Blocks in the overlap will be the current Block, and the other Block(s) will be selected from the entire set of existing blocks.
We then call a custom function that takes the current Block's UID as an argument.
That function picks the current Block (via the UID we just passed it) and repositions the Block randomly.
I only created a function to do the placement because it means we can call the function once when first placing a Block, and again if there's a Block overlap. So, to change how the blocks are randomly positioned, you only have to change the code in one place.
Also, I'm not sure if this was intentional, but in the original capx, the random position ranges start at "32" when creating the Block, but they start at "64" when repositioning a Block after an overlap. In the function based version in the capx I attached, the ranges will always start at "32".
Hope that helps out. :)