I considered this language, but I think it's more clear to use a singular snapshot. I don't want to imply that you would use next-row-id for multiple snapshots.

I'm 60:40 on my version versus yours so not a huge deal if you don't want to change it

You're right. I committed this change. I think I'm just being pedantic.

I think we are missing some of the inheritance path here. The difference between "null" and "assigned and null" I think is getting a little bit mixed up

I think maybe for

For backwards compatibility, readers of any snapshot with a missing `first_row_id` 
must produce null for `_row_id` and `_last_updated_sequence_number` 
for all rows in that snapshot.

I took another pass and updated for this concern. I added:

• New data files are written with a null first_row_id
• Inheritance happens when the manifest has a non-null first_row_id

I think the requirements under this point specifically are okay. When the data file has a first_row_id, the value of _row_id must never be read as null or missing. The missing case is for when the data file is entirely new and has no row IDs. And a data file may have only some rows with null _row_id when they are written by a MERGE statement; we inject a null for inserted rows and preserve _row_id for the updated rows. Similar logic applies to _last_updated_sequence_number and the final sub-point is that rows with non-null _row_id or _last_updated_sequence_number should not have those values replaced.

For backwards compatibility, readers of any snapshot with a missing first_row_id
must produce null for _row_id and _last_updated_sequence_number
for all rows in that snapshot.

I did this slightly differently by stating how to handle a null first_row_id when assigning or inheriting. I think it's a bit more clear this way because it documents each link in the chain, manifest list, manifest, and data file.