Should the value of `error` be mutable?

[ee7]

Example

In perfect-numbers we have this test case: https://github.com/exercism/problem-specifications/blob/8df6cb2ed8e77aa3ac0c02744cd9ddb83920f5f2/exercises/perfect-numbers/canonical-data.json#L121-L130

And we notice (see https://github.com/exercism/problem-specifications/pull/1691) that we would like to make this change:

 { 
     "uuid": "72445cee-660c-4d75-8506-6c40089dc302", 
-     "description": "Zero is rejected (not a natural number)", 
+     "description": "Zero is rejected (not a positive integer)", 
     "property": "classify", 
     "input": { 
         "number": 0 
     }, 
     "expected": { 
-         "error": "Classification is only possible for natural numbers." 
+         "error": "Classification is only possible for positive integers." 
     } 

We seem to have decided that description is allowed to mutate when the "meaning is unchanged" (that is, we do not add a reimplements test case for e.g. a simple description-only typo fix).

The question is: should the contents of an error also be considered mutable when the "meaning is unchanged", or should that require a new test case?

Discussion

My initial opinion is something like:

1. We said that description should be mutable if we don't change the "meaning" of the test.
2. There are some useful error-message changes that don't change the "meaning" of the test either, and the value of error is similar to the "description" of the error. In the limiting case, it seems messy to add a new test case just to fix a typo in an error value.
3. Therefore, directly mutating the error value should similarly be allowed when the "meaning is unchanged".

Drawbacks:

• Is there a track that asserts something about the contents of the error message for this kind of test? Such a track would have to update that assertion, even though their tests.toml didn't change.
• The CI check for immutability would need to check that expected doesn't change, but make a special case for an error-only change.