With some settings the rotating anim prints over frames, also you can see that the tab has 2 pixels below the 'cut of' line.

There is nothing that can be done against that at the moment. Title.mui uses a clipping rectangle during its own MUIM_Draw method to restrict the drawing actions to certain regions. However, the throbber animation renders itself completely independent of this and there cannot respect the clipping region.

Also wondering, if the setting is set to centre, the text/images do not get centred (Tab heigh/2) → when tab heigh = max image or font heigh in tab

The centering is done in respect to the complete title object, what ever that might be. And I must repeat myself again: if you are talking about "some settings" which cause trouble you should provide facts (i.e. a description what to do or a saved prefs file) to let me reproduce the issue. Otherwise I will reject future reports immediately without taking a look at them. If you want help from me, then you must help me. I cannot guess every detail, especially if don't tell the detail.

I think we have small misunderstanding here.
I get the point about the throbber, and it can be worked out with some spacing settings to make it fit, but I am referring to the two pixels that are drawn below the intersection of the tab and the main page. (can be seen in the picture)
and this can not be configured. (in other words the border of the tab is drawn 2 pixels lower then it should, should not overlap the main page)

I get the point about the throbber, and it can be worked out with some spacing settings to make it fit, but I am referring to the two pixels that are drawn below the intersection of the tab and the main page. (can be seen in the picture)
and this can not be configured. (in other words the border of the tab is drawn 2 pixels lower then it should, should not overlap the main page)

Yes, I know. I was referring to this part of my answer:

if you are talking about "some settings" which cause trouble you should provide facts (i.e. a description what to do or a saved prefs file) to let me reproduce the issue."

A screenshot may be nice to show what you are talking about. But a saved prefs file to let me easily reproduce the issue without having to spend hours tweaking the settings would be much better.

This is something I have told you several times by now. Provide facts, logs, screenshots and make it easy to reproduce an issue. I am not going to accept reports like "it doesn't work" or "this looks bad" without further details about how to reproduce this. If you already did all the work to cause a misbehaviour, why do I have to do it again on myself? Is it really so hard to share your bunch of collected information and bits?

Ok. The situation may look a bit strange, but MUI is behaving correctly. The point is that the frame you selected is one the "thick" ones with a frame size of 3 pixels (the completely round one has 4 pixels), but the "imagery" restricts itself to a one pixel thick line on the outer side with nothing else within the remaining 2 pixels wide area. Since MUI does not make any assumptions about how the frame imagery really looks like - it cannot, especially for bitmap frames - it must take the frame thickness as it is and must draw the frame in the way you see it to ensure correct junctions between the tab frames and the register group frames.

To make it short: MUI behaves correctly and the behaviour is intended, it is just the specific "thick" frames which cause the graphical glitches. With a completely filled frame you wouldn't have noticed it. In contrary you would insist that the way the frames are combined/drawn is fully correct.