An EFCore.PG 8.0 regression was flagged (npgsql/efcore.pg#3001), which happened because the ExecuteUpdate value selector lambda does not get visited inside nav expansion. This means, for example, that updates such as the following cannot be translated:

  await db.Test
    .Where(x => x.TextParts.Concat(arr).Count() == 8)
    .ExecuteUpdateAsync(c => c.SetProperty(x => x.TextParts, x => x.TextParts.Concat(arr)));

In the Where clause, x.TextParts is properly processed, so we get the IQueryable version of Concat; but inside the ExecuteUpdate, it isn't and we get the IEnumerable version.

One fundamental problem in our design is that nav expansion is in core, and therefore cannot be customized or handle any relational-only things. This means that it's impossible to have a relational- or provider-specific operator that accepts arguments which require nav expansion (e.g. navigations, queryable/enumerable distinction as here).

For ExecuteUpdate specifically, we already have plans to lift ExecuteUpdate/Delete to core in order to allow using it in non-relational providers (#31052); once that's done, we can simply add the proper visitation logic in nav expansion. But the general design situation is problematic. This was done.

For this bug specifically, I'm pretty sure the only user-visible regressions are going to affect PG only (because of the array support it already had). So I'll see about hacking around this for now in EFCore.PG, unless we see this raised outside EFCore.PG.