In #46223 we changed the mechanic for determining whether a given set of blocks are dirty vs a previous saved state to check for core/page-list specifically.

The reason is that Page List is a controlled block which users cannot change (because it's "read only" / locked). Only programmatic updates can update the inner blocks such as when the block syncs its inner blocks with the entity records coming back from the REST API.

This is why we exclude it from the dirty checking which deeply compares blocks A vs blocks because programmatic updates might trigger a false dirty state.

However to make this more block agnostic we could instead check for blocks which are "locked" and if they are then exclude them from the dirty state checking. Why? Because locked blocks are supposed to be "read only" for users. Our dirty state is only concerned with whether the user made changes to the Nav block's inner blocks so we should exclude all changes made to locked blocks.

As a follow up let's explore using whether the block is "locked" as the factor to determine whether the block's innerBlocks should be considered for having "changed". This will distinguish between blocks changed by the user and blocks changed by syncing with entities.

Originally posted by @getdave in #46223 (comment)