Nice job!

I was curious why this wasn’t a bug in Craft 4.

Turns out it was, just harder to reproduce: with the same setup, you have to modify a Matrix block’s nested field and add a new site before the draft gets autosaved. The easiest way to reproduce is using JavaScript. With the Status field expanded to show the site select input, and a Matrix block’s nested Plain Text field selected in the DOM inspector, you can run the following JS code:

$($0).val('edit');
$('[aria-labelledby="add-site-label"]').val('2').trigger('change');

And then the same buggy code path will occur, and only the modified Matrix block will get propagated to the new site.

So I cherry-picked the Matrix fix into 4.x (3c692b4).

Then I looked into why the Matrix field’s delta data was getting submitted on both autosave requests in Craft 5, but only the first autosave request in Craft 4 (when editing the entry at a normal human speed).

That turned out to be due to a0e98b3: when we’re passing this.$container.data('modified-delta-names') to Craft.findModifiedDeltaNames(), the array is passed by reference so Matrix sub-field’s delta name ends up getting appended to this.$container.data('modified-delta-names') and then gets tacked on to each subsequent save request. So the modified delta names get added onto each time you edit a new field, rather than each autosave only posting the fields that have changed since the last autosave, like it’s supposed to work.

That core bug sortof exists in Craft 4 as well, although it’s inconsequential there. So I fixed on 4.x as well (fbe700f).

That leaves just the Link field bug. I’m not sure why we were calling setInitialDeltaValue() for that field, and not seeing any negative side effects from removing it, so went ahead and merged that change too.