Muito obrigado pelas etapas de reprodução claras @Don 
Sim, é isso! Duas coisas acontecendo aqui ao mesmo tempo
- O serviço do controle deslizante de carregamento precisa remover a classe
still-loadingdo body - LockOn precisa rolar para o lugar certo
Ambos foram agendados na parte afterRender do runloop do Ember. E como as coisas do ‘lock on’ são tecnicamente agendadas primeiro, elas foram executadas primeiro. E assim LockOn estava sendo executado enquanto todo o HTML do post estava no DOM, mas ainda tinha display: none. 
Este PR moverá a remoção da classe still-loading para a parte ‘render’ do runloop, o que significa que qualquer outra coisa que esteja agendando coisas em afterRender será executada assim que tudo for renderizado e visível:
Concordo! Eu não queria tocar nisso como parte desta correção de bug, mas acho que devemos tentar remover todos esses hacks.
Lendo os comentários no arquivo, parece que foi introduzido originalmente (há 10 anos!) para neutralizar os recursos de ‘restauração de rolagem’ do navegador. Hoje em dia, usamos history.scrollRestoration = false para desativar esse recurso do navegador, então acho que isso torna a maioria dos hacks antigos redundantes.
Provavelmente é melhor testar esse tipo de alteração sensível por meio de um componente de tema primeiro e, se tudo parecer bom, poderemos mesclar no core. Imagino que remover LockOn corrigirá muitos outros casos extremos que temos com a posição de rolagem do tópico. Tentarei testar isso nas próximas semanas 