Да, понятно

а что понятно?) и про что речь в 'так и думал'?
интересен ход мысли)

По куче разных причин) статистика, параметры, изменилось количество строчек итд

не могу их найти, смог найти только это

для обоих запросов все по нулям в memory grants

Понятно стало ещё по 15.0

Вариация в планах подозрительна, подозревал новые возможности сиквела.

а можно как-то объяснить, зачем во втором плане нужны top и compute scalar?

1. Выяснить почему форма плана именно такая можно анализируя сам план, а не его фотографию.
2. "Почти одинаковые запросы" не обязаны иметь одинаковые планы.
3. В вашем случае может быть, например, поэтому
drop table if exists #t;
create table #t (id int primary key, v1 int, v2 int, index ix_v2 (v2));
insert into #t values (1, 1, 1);

declare @id int = 1, @v1 int = 2, @v2 tinyint = 3;

set statistics xml on;
update #t set v1 = @v1 where id = @id;
update #t set v1 = @v1, v2 = @v2 where id = @id;
set statistics xml off;

Не знаю в чем причина, может более знающие коллеги подскажут.

Зачем мне планы из моего-же примера? :)

я думал, вы поможете по планам определить в чем суть)

тут что-то про несоответствие типов?
tinyint <—> int

Я вам в примере показал в чем суть - она в индексе по одному из столбцов в апдейте.

Пригодятся.

честно говоря, стало еще менее понятно..
в обоих запросах одинаковые предикаты поиска

Подробнее - если в апдейте изменяется столбец, включенный в некластерный индекс, то сначала будет вычислен флаг, показывающий будет ли реально изменено значение такого столбца.
Это надо для исключения ненужных некластерного индекса, ибо это дорогая операция.
Поэтому такая форма плана - Clusterd Index Seek - Compute Scalar - Clustered Index Update

Смотреть нужно свойства не корневого оператора, а Clustered Index Update. Если обновляется какой-то индекс, то он там будет указан.

А почему два compute Scalar и зачем нужен top?

Не могу сказать - не разбирался с этим.