Currently the Java SDK at least (and probably others) just passes on error strings from ep-engine to the end user (in Java client, via a getMessage() method on OperationStatus object, for example). In java client this is the only way to get what kind of error happened (e.g., if an add() operation fails, was it tmp oom error, or item already exists? or server is down? only way to know is look at the string from getMessage()).
Implies that the error string reported by ep-engine is part of the API, currently. Ideally all clients would have error code enumerations, and error strings could be improved over time. But until that is in place, and the current string-oriented error checking is deprecated, we should not change the error strings or risk breaking application code in subtle ways upon server upgrades.
To ensure that error strings do not change without taking the API-breakage into account, we should have a unit test that ensures that checks the error messages explicitly. And that unit test should be well-commented to ensure that engineer doesn't just modify the strings and the test case without understanding why the tests exist in the first place.