Vielen Dank für die klaren Reproduktionsschritte @Don 
Ja, genau das ist es! Hier passieren zwei Dinge gleichzeitig
- Der Lade-Schieberegler-Dienst muss die Klasse
still-loadingvom Body entfernen - LockOn muss zum richtigen Ort scrollen
Beides war im afterRender-Teil von Embers Runloop geplant. Und da die ‘Lock On’-Sachen technisch zuerst geplant wurden, wurden sie auch zuerst ausgeführt. Und so lief LockOn, während der gesamte Post-HTML im DOM war, aber immer noch display: none hatte. 
Diese PR wird die Entfernung der Klasse still-loading in den ‘render’-Teil des Runloops verschieben, was bedeutet, dass alles andere, das Dinge in afterRender plant, ausgeführt wird, sobald alles gerendert und sichtbar ist:
Einverstanden! Ich wollte das im Rahmen dieser Bugfix-Änderung nicht anfassen, aber ich denke, wir sollten darauf abzielen, all diese Hacks zu entfernen.
Wenn man die Kommentare in der Datei liest, sieht es so aus, als ob sie ursprünglich (vor 10 Jahren!) eingeführt wurde, um die ‘Scroll-Wiederherstellungs’-Funktionen des Browsers auszugleichen. Heutzutage verwenden wir history.scrollRestoration = false, um diese Browserfunktion zu deaktivieren, daher denke ich, dass dies die meisten alten Hacks überflüssig macht.
Wahrscheinlich ist es am besten, diese Art von sensibler Änderung zuerst über eine Theme-Komponente zu testen, und wenn dann alles gut aussieht, können wir sie in den Core integrieren. Ich stelle mir vor, dass die Entfernung von LockOn viele andere Randfälle bei der Topic-Scroll-Position beheben wird. Ich werde versuchen, dies in den nächsten Wochen auszuprobieren 