Ties in tablature: vertical position wrong and ends hidden behind fret marks

See this: #30631: Improper layout of tablature ties

So this has been going on since v2? Yet the ties move down/up when I open a v2 score in v3 and select "reset to default positions".
I just created a new score in v2.1 and this issue is present there too. So it predates this issue page by one sub-version.
It's an unrelated circumstance that causes me to have 2.1 as my version 2 installation.

to clarify - The reason this is a Major issue is that there is no workaround. You cannot set the Tie styles only for tablature. Those style settings affect all ties in all staves.

AFAICT, the bounding box used by TieSegment::layoutSegment() is not correct, and may be because the bounding box for the tablature note is for the text of the note head, not the background whiteout rectangle, which is bigger than the note head. I'm looking further into the cause, but the solution appears to be a specific adjustment inside TieSegment::layoutSegment() for tablature note heads. Possibly a new Note::getOuterBBox() function would be the best way to do it, not a manual adjustment inside class TieSegment.

Here are two images of two different adjustments to the tab tie y-coordinate. The first subtracts 1.75, and the second subtracts 4.
1.75 is the extra height at the top for the background whiteout rects,. To my eyes, they both eliminate the cropping, so the 1.75 is a minimum, which works for me. Any contrary opinions?

Note that the by default tablature staff lines are separated by 1.5 * the spatium, 37.5 versus 25. The height of the whiteout rect is based on one tablature staff space = 37.5 by default. The height of the FreeSerif font at 9pt is 34. The whiteout rect is 3.5 taller than the text, thus it is positioned 1.75 higher than the text.

I attached the image files themselves so you can zoom in and see the pixels. I zoomed in to 500%, and the cropping is eliminated in both images, AFAICT. This is a screenshot of a double-zoomed-in MuseScore too. You gotta look closely at these things...

The y coordinate is easy, it's the x-coordinate that is funky. The whiteout rect calculates it by shifting the note head (text) x-coordinate by 0.1 * the spatium, by default that's 2.5. I don't know from where the factor of 0.1 derives, and the spatium is a vertical value, not horizontal. I don't know why you'd want it wider just because you user taller staff spacing, or narrower if you use shorter staff spacing.
This code is in one place only, Note::draw(), here:
https://github.com/musescore/MuseScore/blob/245e0424049f167ad47d6470514…
I also don't know if it is desirable to change the ties' horizontal positions. If this is just a y-coordinate issue, then I'll provide just that value to the Tie class. No need to mess with x if it looks right in the current master. That y value is already available the same way the Note::draw() gets it:
const StaffType* tab = staff()->staffType(tick());
y = tab->fretMaskY() * magS();

https://github.com/musescore/MuseScore/pull/4673
I only adjust the y-coordinate, not the entire bounding box; x is unchanged. The new code adjusts the translation that is applied to the slur/tie in TieSegment::computeBezier(), early in the layout/draw process.
This makes the minimum position change, 1.75, plus 0.2 * the spatium, for a total of 6.75 at the default spatium value of 25. 1.75 looks OK when zoomed in, but in default resolution on my HD1080x1920 monitor the tie touches the tab number. 0.1 didn't do the trick, so I settled on 0.2. It looks good to me, even better than the tie on the two standard quarter notes in the top staff. Here are screenshots in default and zoomed resolution:
  
Feedback is appreciated. I made a judgment call on how far to move the tie, and I based it on the score's spatium, which seems appropriate for a y-coordinate, but if not, let me know.

also note - for this example score, adding -1.75 to the tab note y offset makes it equal to the quarter note above it: -18.75. For a default tab staff, that is half the staff space value of 37.5. The quarter note's tie is translated by 18.75 already. The original value of the tab note tie's y offset is -17 = -34 / 2.
I set it to -18.75, then I move it up by an additional -5 = 0.2 * 25; to -23.75.
Those numbers are in internal MuseScore units @360dpi. That's close to the 300dpi of many printers. My 24" 1920x1080 monitor is running at 92ppi. An 8K monitor this size would be 4x that resolution = 368ppi. Some iPhones and other HDish smaller monitors, as well as 4K and 8K monitors, achieve 360ppi or higher, but it's not common for screens yet. It will be...

That PR closed itself after a rebase. The new PR is here:
https://github.com/musescore/MuseScore/pull/4804

The pull request was merged but this is issue was not closed automatically due to a missing space between "fix" and "#88411" in the commit message.

It needs a space? I better fix another PR right now...