address the comments

Author: jun-he

site/docs/spec.md

@@ -170,6 +170,7 @@ Partition specs capture the transform from table data to partition values. This
 | **`month`**       | Extract a date or timestamp month, as months from 1970-01-01 | `date`, `timestamp(tz)`                                                                                   | `int`       |
 | **`day`**         | Extract a date or timestamp day, as days from 1970-01-01     | `date`, `timestamp(tz)`                                                                                   | `date`      |
 | **`hour`**        | Extract a timestamp hour, as hours from 1970-01-01 00:00:00  | `timestamp(tz)`                                                                                           | `int`       |
+| **`alwaysNull`**  | Always produces `null` (the void transform)                  | Any                                                                                                       | `void`      |
 
 All transforms must return `null` for a `null` input value.
 
@@ -646,18 +647,25 @@ Each partition field in the fields list is stored as an object. See the table fo
 
 In some cases partition specs are stored using only the field list instead of the object format that includes the spec ID, like the deprecated `partition-spec` field in table metadata. The object format should be used unless otherwise noted in this spec.
 
-#### Partition Field ID handling
+#### Partition Field ID Handling
 
-A partition field id is an integer (starting at 1000) used to identify a partition field.
+A partition field ID is an integer used to identify a partition field.
+These IDs should not conflict with the IDs required for the other fields in data files.
+To avoid that, iceberg assigns partition field IDs starting at 1000.
 
-Since iceberg release 0.8.0, partition fields are present in every partition field of partition specs in a table metadata.
+The requirements below are for different versions of tables:
 
-* For backward compatibility, if field ids are missing in a table metadata, iceberg will sequentially generate ids for each field starting at 1000 based on its position in the list of fields.
-* For forward compatibility, if field ids are not supported, iceberg will ignore field ids.
+* For v1 tables, partition field metadata should include a field id for each partition field, but this is not required.
+* For v2 tables, partition field metadata must include a field id for each partition field. Partition field IDs are unique across partition specs to support the partition spec evolution for a given table.
+
+To remove partition fields from the partition spec in an existing v1 table, it is recommended not removing fields but replacing their transforms with `alwaysNull`.
+Otherwise, partition spec evolution will break because a partition field ID might be assigned to multiple different partition fields during partition spec evolution for a given table.
 
-Additionally, in table metadata format v2, partition fields are required to have unique field IDs to support partition spec evolution.
+For compatibility between v1 and v2 tables:
+
+* For backward compatibility, if field ids are missing in a table metadata, iceberg will sequentially generate ids for each field starting at 1000 based on its position in the list of fields.
+* For forward compatibility, if field ids are not supported but present in the metadata, old versions of the reference implementation will ignore those field ids and then regenerate an auto-increment field id starting at 1000 for every partition field.
 
-For tables without partition field IDs, iceberg will generate an auto-increment unique field id starting at 1000 for every partition field.
 
 ### Table Metadata and Snapshots