Rather than using the diff to update the backing store, implementations should reject the commit if the current state doesn't match the caching state.

This is because we may not be able to correctly infer the change based on the diff.

Example:

 A gets hostinfo
 B adds foo label
 A checks if foo exists (it doesn't for its hostinfo), adds spam label
 We incorrectly infer that A wanted to add spam label
 Now hostinfo is in illegal state (both spam and foo labels)

 A gets hostinfo
 B adds foo label
 A checks if foo is missing, adds spam label
 We notice that hostinfo has been changed, tell A to retry
 A gets new hostinfo
 A checks if foo is missing, finds foo, does nothing

In other words, we want to implement transactions =(.

We may decide that the probability and damage of such race conditions isn't worth implementing this correctly, but this assumption has to be re-evaluated for each new piece of label or attribute logic that's added in the future, which accrues continuous interest.

Bulk closing Infra>Client>ChromeOS issues untouched in over a year.