My testing found that \offset didn’t work with outside-staff-padding for OttavaBracket grobs.
That's great, because with this method the user is not forced to use a ruler. Then, the best one. I just tested it and now we can say that, in order to shift vertically a bracket, the user should follow this rule:
1) \override + outside-staff-padding increased of 0.46 (if you want to preserve the automatic collision avoidance)
OR
2) extra-offset (as a final tuning, if you don't need automatic collision avoidance)
OR
3) \override X/Y-offset with a ruler with staff-space units and a starting set on the middle of the staff (if you need automatic collision avoidance)
It is *very* unlikely that you will find a single approach that will work with *every* grob. You may be able to find approaches that will work with classes of grobs. You may need to have individual approaches that apply
to specific grobs.
Yeah, no surprise for me. But I asked. You never know...
It appears that much or your dissatisfaction is because you thought you had found a trivial solution (i.e. use \offset Y-offset) only
to find that it doesn’t work.
You are wrong. Not only I'm not dissatisfied: I'm seeing that all these work even better than I could imagine some days ago. Really great and powerful. What made me upset is that there's not a clear blacklist of the unpredictable properties for a given grob. Nor this is documented or warned. Then I think we all had headache in discovering the right ones for the Bracket. Please don't misunderstand these words: it's not a criticism at all for Lilypond. I work every day with open source projects, and this kind of issues are absolutely normal for them. We are all volunteers. The more the project is complex, the more you find issues or undocumented features.
If you felt that I wanted to blame a behavior of Lilypond, please delete this idea.
HTH
Paolo