in 3.5.0beta2 the to front/background does work, but the activated control will still be brought to front in live mode (well, rendered on top, when you switch to another window and back, it will be restored to its original position).

Having said all this: What it the point in having overlapping form-controls? I cannot see a real reason for it.

Please provide a sample where overlapping / stacked controls are necessary.

Created attachment 54949 [details]
Screenshot illustrating two examples of the usefullness of stacking controls

Is the request for information in order to assign an importance/priority to the bug?  I ask because the question sounds like what is being debated is whether or not the feature should be part of LO in the first place.

Anyways, here is the case for working control stacking:

Background: Screen real estate for forms that have complex information can be very much at a premium.  This is especially the case if the form has aesthetics as a design consideration, where visual elements take up some of that valuable real estate.  In many cases, squeezing controls closely together can be a challenge if stacking order is not honoured.  In other cases, adding in aesthetic elements can be impossible without correct stacking order.  Attached to this comment is a screen shot of a Pathfinder RPG spell database form that illustrates two instances of where failed stacking order impedes a form's design goals:

Situation 1, Label field impinging on data field borders
It is difficult at times to get the text of a label field as close as one would like to the data field it is labelling without the border of the label field impinging on the data field.  You will notice in the area labelled "Situation 1" that the label is overlapping the top of the text box.  Even using the vertical alignment setting in a label doesn't always help, depending on the font selected.  Fonts with deep descenders (like the underlined label on the scroll) cause more of a problem and I ended up not being able to use the font I wanted because I could not effectively set the stacking order so that the text boxes were and stayed on top.  Which makes for very ugly looking text boxes when their borders are overwritten by labels.

Situation 2, Cannot put visual elements on top of controls, even when the visual elements are themselves a control.
In order to save some space labelling, and to make it (in my opinion) visually more appealing, I decided to label some of the text boxes with partially transparent labels.  I quickly noticed that it is absolutely impossible for the stacking order of any non-control element to make it appear over top of a control.  This, I believe, is a design issue and will be addressed by a feature request.  However, since using normal Draw-style text boxes for this was out of the question, I switched to an image control.  I created my partially transparent image with no problem, but even with an image control I still could not get the image to reliably stay on top.  It is displayed on top in the attached screen shot, but will disappear underneath if any one of dozens of cases.

There are two detailed situations.  In reality, though, there are a myriad of cases where stacking order is important for form element.  Whether it's something as simple as reducing the time it takes to develop by not needing to bother to be picky about where label, checkbox, radio button, etc borders end (a separate issue from not being able to get labels as close as one would like to other elements), to using stacking order as a method of dynamic control selection, to overlaying buttons or controls over unused areas of other controls to save space.  It's an important feature and I cannot think of any other form design software that omits it.

Incidentally, the stacking order for table controls in 4.4.x does not work at all, in any circumstance.  No other control will ever appear in front of a table control.

Adding self to CC if not already on