AIP-193 review feedback and add a dated changelog entry

Author: jskeet

aip/general/0193.md

@@ -55,8 +55,7 @@ error, and offer an actionable resolution to it.
 
 For pre-existing (brownfield) APIs which have previously returned errors
 without machine-readable identifiers, the value of `message` **must**
-remain the same for any given error, as developers have previously had no
-option but to use this for error handling. For more information, see
+remain the same for any given error. For more information, see
 [Changing Error Messages](#changing-error-messages).
 
 ### Status.code
@@ -82,15 +81,9 @@ example, there **must not** be more than one [`BadRequest`][BadRequest]
 message in the `details`, but there **may** be a `BadRequest` and a
 [`PreconditionFailure`][PreconditionFailure].
 
-Structured details with machine-readable identifiers **must** be used so
-that users can write code against specific aspects of the error. Error
-message strings **may** change over time; however, if an error message
-does not have a machine-readable identifier *in addition to* the message,
-changing the error message **must** be considered a backwards-incompatible
-change. For more information, see
-[Changing Error Messages](#changing-error-messages).
-
-All error responses **must** include an `ErrorInfo` message within `details`.
+All error responses **must** include an `ErrorInfo` within `details`. This
+provides machine-readable identifiers so that users can write code against
+specific aspects of the error.
 
 The following sections describe the most common standard detail payloads.
 
@@ -430,7 +423,7 @@ change. This is one reason for introducing `LocalizedMessage` into the
 
 RPCs which have **always** included `ErrorInfo` are in a better position:
 the contract is then more about the stability of `ErrorInfo` for any given
-error: the reason and domain need to be consistent over time, and the
+error. The reason and domain need to be consistent over time, and the
 metadata provided for any given (reason,domain) can only be expanded.
 It's still possible that clients could be parsing `Status.message` instead of
 using `ErrorInfo`, but they will always have had a more robust option
@@ -444,6 +437,7 @@ available to them.
 
 ## Changelog
 
+- **2024-10-18**: Rewrite/restructure for clarity.
 - **2024-01-10**: Incorporate guidance for writing effective messages.
 - **2023-05-17**: Change the recommended language for `Status.message` to be
   the service's native language rather than English.