In SQL Server, perché una scansione all'indietro dell'indice cluster non può usare il parallelismo?

Ho letto degli interni di SQL Server e ogni libro o blog menziona questo riguardo le scansioni all'indietro.

Una scansione all'indietro di un indice cluster non può usare il parallelismo

L'unico post che ha detto qualcosa è questo qui sotto. Il post afferma che il team di SQL Server non ha implementato le ottimizzazioni richieste per una scansione all'indietro. https://www.itprotoday.com/sql-server/descending-indexes

Poiché le pagine a livello foglia sono collegate utilizzando un elenco doppiamente collegato, non capisco perché una scansione all'indietro sia diversa da una scansione in avanti. Ogni chiarimento è molto apprezzato.

L'articolo a cui si fa riferimento afferma specificamente che il motivo per cui le scansioni ordinate all'indietro non sono state parallelizzate in SQL Server 2008 (a partire da CU6) non è tecnico, ma perché la funzionalità non era stata richiesta dai clienti e il team di sviluppo non si è preoccupato di implementarla.

Si noti che l'articolo è stato scritto quasi 10 anni fa nel contesto della versione di SQL Server 2008 ora non supportata. Sono stati apportati cambiamenti significativi al motore di archiviazione e all'ottimizzatore. Detto questo, vedo ancora un piano parallelo per la ASCquery e un piano seriale per la DESCversione dalla query demo dell'articolo su SQL Server 2017:

SELECT *
FROM dbo.Orders
WHERE orderid <= 100000
ORDER BY orderdate ASC;

SELECT *
FROM dbo.Orders
WHERE orderid <= 100000
ORDER BY orderdate DESC;

L'esecuzione delle stesse query in SQL 2019 CTP 3.2 mostra un piano seriale per entrambi, a meno che non abbia modificato la query in WHERE orderid <= 50000, dove ho osservato lo stesso comportamento di SQL Server 2017. Quindi sembra che la scansione all'indietro parallela non sia ancora stata implementata o è necessario uno scenario diverso per osservarlo.