Динамический список, ClusteredIndexScan и COMPATIBILITY_LEVEL=130

Всем доброго дня.
Поставила меня в ступор следующая ситуация.

Есть справочник (журналирование), перекочевавший во внешнюю базу с минимальными изменениями (секционирование, сжатие, измененное индексирование). Подключена база внешним источником.

Имеем таблицу с кластерным уникальным индексам по полям Period+ID
Period - datetime2, ID - binary(16). Колонок > 2 (с десяток).
Таблица и кластерный индекс одинаково секционированы (одной функцией, по кварталам) по полю Period, в таблице под 40 млн записей.

Имеем запрос динамического списка внешнего источника вида
SEL ECT TOP 45 * FR OM [dbo].[Table] t
WHERE t._Period >= {ts '2018-08-01 00:00:00'}
order by t._Period, t._ID
(последовательность условия, сортировок и направления сортировок совпадают с CI. Т.е. все идеально)

На совместимостях 110, 120 - работает прекрасно (CIseek).
При переключении на совместимость 130 - CIscan.
"Хм", подумал я... и пошел забавляться с флагами трассировок, статистикой, перестроением индекса и т.д.
Самое странное, что это даже не новый оптимизатор, т.к. на 120 - все ок (хотя как знать - новый активно развивают).

Оказывается, скуль (130) невзлюбил формат даты (_Period >= {ts '2018-08-01 00:00:00'})!
Любые другие варианты работают отлично
WHERE T._Period >= convert(datetime2, {ts '2018-08-01 00:00:00'})
WHERE T._Period >= '2018-08-01'
и т.п. - всегда CIseek

Может кто-нибудь объяснить В ЧЕМ ФИШКА?
Что случилось, если на более ранних совместимостях все прекрасно работало? Какие-то изменения может были правилах применения форматов дат?

PS: СУБД - mssql 2016 sp1 cu8