Ok, and for bonus points, you’ve actually found three bugs here - though only two of them are ours …
I woke up with the nagging thought “how did the initial import even look right in the first place??” given that we’d already mangled 8.996 to 8.100 at that point … and given that subtle math bugs often come in clusters it seemed worth doing a bit more checking.
And it seems the answer to this is: when you first import and offset this SRT, we create that invalid three decimal place 8.100 timestamp which we pass to MLT who passes it to ffmpeg - and ffmpeg interprets that as 100 x 10ms not 0.100 sec - as do we when we display the clip on the timeline. [And if you look very closely we round that to a frame number differently to them, and the subtitle isn’t actually rendered in the monitor when you place the cursor on the first frame of the last timeline clip, it appears one frame later than that.]
It then breaks more obviously after you round trip it by saving and loading it, because unlike the SRT converter, our old/current ASS parser sees 8.100, interprets that ‘correctly’ as 8.1, then rounds it to 8.08 which is the nearest frame boundary. And that’s what will end up in the saved file instead of 8.100 if you save it for a second time, at which point the error becomes stable.
That doesn’t change that it’s already fixed in the new code, and that us not passing an invalid ASS timestamp to ffmpeg makes its handing of that moot - but I figured I’d note the full story for posterity in case there is another case/place this shakes out in again later (and I need to remember what we figured out about it Last Time : )
[linking this to 24.12.0 subtitle editing to remind me to add unit tests for cases like this.]