This was easily one of the hardest bugs to track in my entire career. I have probably spent more than 40 hours chasing it.
So in the end it is a bug in Apples code which reports the current playback position of the audio player node. The bug only occurs in the production build of the app distributed through the App Store. That made hunting for it and searching for a workaround very time consuming as I needed to submit the app to the AppStore every time I made a change.
Whenever there is a speed change fx active, or was active the last time playback was running, there is a chance that the reported time is off. This does not happen every time and what makes it especially annoying is, that it does not happen right away after playback starts. The first 1 or 2 buffer cycles (about 1-2 millisecond each) report the correct time. Only after 1 or 2 cycles, the position jumps ahead. This delayed occurrence cost me a lot of time to find out and by that I really mean a lot. These are the times where I really question my life choices.
I have now a workaround that seems to work fine for this issue. ST3 now checks the playback time 0.1 seconds after playback is started. ST3 knows which time is expected to be reported at that time. If there is a deviation it will calculate the delta and apply it to the displayed time so that time, position and scrolling/highlighting will be accurate again. Small downside is that the position indicator still might jump for a split second.