Ties in imported (2.x) tablature have wrong horizontal placement: fixed by saving and reloading

Can you re-check in a current build? Tie layout has changed. I can see results are a little different from 2.x, but not to the extent that I'd call it a bug.

Looks like the layout is taking into account the stems that of course are not present. I'm not sure there are any good definitive rules for the layout should look (Gould doesn't cover tablature), but it would be good to consult such a reference if it exists.

I cannot say with certainty what happens when you open this v2 score in v3 MuseScore, but it looks identical to something I'm seeing with new scores in v3 MuseScore: the tablature number is shifted too far to the left. It's the left (origin of the tie) note moving leftward, not the tie being poorly positioned.
Using "full" tablature with stems illustrates the issue more clearly, visually. I think using the stems is the ideal way to horizontally position the note heads (numbers). The number should always be centered under the stem. @geetar's comment above mentions centering too.
The problem I'm seeing with a new v3 score is irregular horizontal alignment relative to the stem. Some look good, others not so much. It's always too far left, never too far right. When I resize the measure by adding an accidental or a lyric, the numbers shift around as demonstrated by these three images:

The number 8 is an easy number for visualizing its center. The second image, with the accidental in the linked notation staff, aligns better than the original all 8s measure. The first two 8s in the first image are too far left, for example. The third image, 8688, has no accidentals, but the 3rd and 4th numbers are shifted farther left than in the all 8s measure. Here is the score, created just now with the latest master, in case you want to play around:
tabtest.mscz

Also note the stem position relative to the note head in the two notes that are circled in green. By adding an accidental to the 4th note in the measure, the stem of the 2nd note moves right, relative to the note head. This is a zoomed in view in MuseScore, which might make the difference, but I wanted to note this. You can reproduce it by zooming in one level with this score and changing that note's pitch.

So it looks to me that the code might not be positioning the note heads relative to the stems. I'm in this code attempting to truly center these things, but the bboxes are positioned incorrectly on the canvas/page. I have yet to figure out the alignment-assignment order. I'm working with linked notation/tablature staves, which should align with each other too - but how?
What are the rules for horizontal alignment of tablature and notation note head/stems?
I would think that the note heads should center align, and the stems would follow. Up/down stems for notation align differently anyway. Tablature stems horizontally align the same irrespective of vertical position.
In this zoomed image, you can see that, relative to each 8, the first two note heads are aligned one pixel to the right of the second two noteheads. This is a screenshot from a bitmap editor, and the original bitmap is of a zoomed-in MuseScore, which might contribute to these one-pixel differences. These differences might not exist at the normal zoom level in MuseScore.

In debugging, I have just confirmed the layout order is by measure, left-to-right. Within a measure it is:
1. Stems by staff, in tick order
2. Notes by staff, in tick order
3. Notes by tick, in staff order
I am not certain yet, but this order suggests that the note head position is based on the stem position. Stems are laid out first.
It also indicates that there is an extra layout step executing for class Note.

For standard notation note heads, the x-coordinates are identical to the stem. For tablature that is not the case. If the stems are laid out first, that convolutes the notion of aligning tablature note heads. I still have more to understand here before I can come up with a fix. Any additional info is welcome.

Here is example debug output of the page/canvas position x and y values for one measure my tabtest.mscz file:
TYPE x-coord y-coord
stem 343.904 582.303
stem 408.543 569.803
stem 486.246 569.803
stem 550.885 557.303
stem 362.654 853.857
stem 427.293 853.857
stem 504.996 853.857
stem 569.635 853.857
note 343.904 565.686
note 408.543 553.186
note 486.246 553.186
note 550.885 540.686
tab 351.154 811.732
tab 415.793 811.732
tab 493.496 811.732
tab 558.135 811.732
note 343.904 565.686
tab 351.154 811.732
note 408.543 553.186
tab 415.793 811.732
note 486.246 553.186
tab 493.496 811.732
note 550.885 540.686
tab 558.135 811.732

I have found the code that sets the page/canvas x coordinate for tablature, but not for notes, here in Chord::layoutTablature():
https://github.com/musescore/MuseScore/blob/5e30acdfc3bd5146fd05a465d9e…

It is definitely based on the stem, but how is Stem's _offset variable set? The _pos appears to be always set as a contant of 0.75 here:
https://github.com/musescore/MuseScore/blob/5e30acdfc3bd5146fd05a465d9e…
and the tablature Note's _pos is apparently centered on the stem via stemX - fretsWidth*0.5 in layoutTablature(), the first link above.

The only place I see a non-tablature Note's _offset being set is here, from the XML value, in ChordRest::readProperties():
https://github.com/musescore/MuseScore/blob/5e30acdfc3bd5146fd05a465d9e…
Is that it?
_offset is the relevant variable here, AFAICT.

Upon zooming in further, I see that the tab numbers that are not properly centered are not properly centered within the page-colored rectangle that is behind them to block the staff line. Those misaligned numbers are not centered in the whitespace provided. So everything looks OK, except the numbers, class Note.
Yet in spite of looking irregular on the screen, all the x-coordinates line up identically: offsets, positions, paint/canvas positions, all of them. So far, I am still mystified.
I'm starting to look at this in SVG as well. It might be a useful point of comparison.

This looks good to me. See the attached .mscx file, which probably won't look the same for you inside MuseScore. This is my same code that centers tab notes using text alignment. It looks great on Ubuntu Linux. It does not look so good on Windows 10. Could the operating system really affect this that way? The original poster is on Win10, so is Marc, IIRC. I'll confirm that the master looks this same way, or if my code fixes this on Linux. Here is an image from the master:

My code seems to be an improvement, but it's still not right on Windows. All of this looks worse on Windows.

Interesting results. I have not reproduced this improvement, except that my branch's saved file looks slightly better than a new file. But maybe the ties are a separate issue from the note heads after all.
On the other hand, here is a blue line on top of a screen capture of the previous comment. Note how the all the stems and note heads are a pixel more to the left in the unsaved score file's image, the top image:

Of course that is not 100% reliable, comparing two screen captures one after closing and reopening the score - I don't know what else might shift the view 1 pixel to the right. But the direction is in line with my observations.
EDIT: I just added a second blue line for the other end of the tie. Those stems and note heads are shifted one pixel too. That means the tie's position did change, relative to the note heads.
I also added a red line that confirms the separate shift for the tie. The tie shifts leftward, not rightward in the 2nd, saved file image.

@geetar - did you click Yes or No when prompted by MuseScore 3.0 to reset the position of all elements? For me, that moves the ties vertically down, but does not adjust them horizontally. It is likely irrelevant here, but I'm curious all the same.
I am reproducing your save in the 3.01 format (as a separate file), closing then reopening behavior in Windows. I have the two scores open side by side right now and it is only the ties that are lengthening leftward.
I have opened a separate issue for this here: https://musescore.org/en/node/284027
but I'm going to post this final image of your score with common tablature and stems in MuseScore v2. I adjusted the font and font size to be the same as your original. This misalignment of tablature note heads to stems is the same in v2 as v3. With this multi-voice score and opposing stems, you can see that the stems for a single tablature chord are not aligned either:

Did you notice that they moved lower after you clicked Yes? You can always try it again, as you have the original v2 file.

Regarding that downward shift for the ties. I notice that vertical centering of tablature notes on the staff lines is off by 1pt/px in MuseScore at this time. The note heads are centered 1pt/px below where they should be. And in spite of being just slightly too low, the ties get cropped by the background rectangle ("whiteout" rect). This is in Linux too, not just Windows. I've tested with different fonts and sizes, the tie moves with the font size.
See the attached score. Zoom in and look at the tips at either end of the tie between the two tab notes. The tips are cropped off.
That downward tie "default" repositioning affects the tab staves, not the notation staves, and should probably be considered a bug, where v2 does it right, v3 moves them too low. This Linux screenshot clearly illustrates the cropping in the lower staff's tie:

This next image is from an SVG export of this same score (my svggenerator code, not the master). It centers everything precisely, and here it increments the text y-coordinate by 1pt/px to mimic MuseScore. But it uses much shorter whiteout rects. It may not be cropping, but the tie is too definitely close to the numbers, vertically:

I just peeked at the extended tablature glyphs in mscore_tab.sfd, the source font file. MuseScore's vertical centering on the string/staff lines is actual 2pt/px too low, not 1. In my previous comment I was only looking at numeric glyphs/characters, with nothing below the text baseline, like the letters g, j, q, or y. Those renaissance, alphabetic tablature note heads have plenty of glyphs/chars that go below the baseline. Numbers never go below the baseline, at least not 0-9.
I believe this is the same in v2 as v3, and no one is complaining. I just don't know who uses those extended glyphs, to ask their opinion about this positioning. I only use standard, modern tabs, and I prefer to center vertically on numbers, not full-height characters. MuseScore is still off, either way, and the ties are off even more.
Here's a screenshot of that tabtest2 score with the basic renaissance tab font. The zeros, threes, and fives get cropped, maybe the one too:

I just figured out how to use the other fonts to get those extra glyphs to display. In general the extended glyphs all seem to treat the string/staff lines as the text baseline, though for some of the fonts it's even lower. Here are some images - there's plenty of cropping, some extreme: