This is not really an answer to your question…but, for Window at least, it is not recommended to overlay controls over each other. I’ve not noticed any issues with Z order in the IDE but I don’t really overlay controls so I rarely pay attention to the Z order. You might be able to open your old project in the latest version and fix the deprecations and give it a try.
I have two controls (a sheet-window button and a date/time selector button) that at runtime I want to occupy the same spot on the layout. For ease during development I site one 40 pixels east of the other on the layout, and then at Opening time I move it 40 px west. Only one should be visible at once, so I use .Visible to manage that and the approach appears to work.
It is mainly where I have a Canvas in the background, giving some color and fashion to the dialog, and the controls are on top of it. There are instances where a PushButton is invisible, then I set Visible=True, and the Canvas is on top of it so it doesn’t even show. But at design time I can see the control. (And I’m not even going to talk about the times where the control.Visible=True and doesn’t appear but you can still click in the area and it works.)
Disappointing, I thought Xojo/Real would have fully dealt with this by now. It’s been years, if not decades. The responder who said “best not to overlay controls” seems unfortunately correct. I can abide by that advice mostly, but it’s hard when I want a window/dialog to look better than just the utilitarian gray/other and I want a Canvas as a backdrop.
In the IDE, you should send the canvas to the back. Then at run-time the ordering will be correct. I have a number of canvasses with several controls on the canvas. That is the way to make that set of controls be scrollable together.
Back when Joe R was working for Xojo, he helped me with a great many things (as did Norman). The rule of the thumb is that the Xojo runtime likes to maintain the view hierarchy atop the macOS, but the Xojo framework is missing a lot of functionally (there are feedbacks for some of it), meaning if you want to use 'em, you have to use declares and go behind the frameworks back, which can lead to problems if you’re trying to do something a little more complex.
When you use declares to alter the view hierarchy, you’re moving the control behind Xojo’s back and thus it can lead to all kinds of problems as the Xojo framework doesn’t know and will continue to use values from before.
It why Listboxes don’t work correctly on Popovers (there’s feedback for Xojo to provide popovers and feedback for Xojo to help those of us who want to use popovers).
But my main issue with how to do it on the Mac is, if you want to bring a view/control forward when clicked by the user, you must move all other relative views backwards, otherwise it breaks the mousedown event.
Not sure if this is relevant, but I had a similar situation recently with a canvas on top of another canvas, with the top one not being visible at runtime. Here is the trick/hack/workaround that solved it for me: If you drag a canvas onto another canvas in the IDE, you will see the bottom canvas highlight in red, indicating that it’s become the parent or something of the one being dragged. You don’t want this. If I first place the top canvas outside the bottom one instead, so that the bottom one doesn’t show a red highlight, then position the top one using the arrow keys (hold shift for 10x movement) or by entering Top and Left in the Inspector, the bottom one doesn’t highlight and the top one remains visible at runtime. HTH.