set X to centerX + cos(angle) * distance(cx,cy,sprite.x,sprite.y)
set Y to centerY + sin(angle) * distance(cx,cy,sprite.x,sprite.y)
Which will really rotate the object (making the collision follow) and you also give control over the center of rotation. With layer rotation you don't have that control.
Moreover, now that family is on the rail, grouping object to rotate them is a piece of cake. Using Layers to do that also force objects to be in the same kind of zSorting group (we can imagine a game with some complex layering of object regardless of either or not they rotate...)
Anyway, this unfortunately leads to bad programming design like rotating object and creating collision object on another layer and rotating them with the aforementionned formulat just to be in the contest rules.
However, as the associated rule of the rotary contest is "Every game must make use of the system 'Rotate layer' or 'Rotate layout' actions. It must be an important feature of the gameplay and not just added on as an afterthought."
And I think changing it "To allow entries that clearly use Rotation as the core Design mechanic. Even if Rotate layout/Rotate layer are not the actions used to facilitate it?" might arm some entries (for now... maybe just mine :D)
'cause rotation being the "core mechanic" wasn't in the rule. The rule just stated that rotation should be "an important feature" and shouldn't be "added on as an afterthought" so there's a wide range of possibility between "core mechanic" and afterthought.
(in my case layout rotation appears at level 6 and had a level of freedom in the maze)
So if I might suggest something it would be "Every game must make of use or mimic the system 'Rotate layer' or 'Rotate layout' actions. It must be an important feature of the gameplay and not just added on as an afterthought."
But I would also add that changing a core rule one week before the end might not be fair to some people (: