I admit it's less of a slam-dunk case than fixing the normal attribute persistence behavior. Here's my reasoning:

* A system where any new feature, even when written 100% correctly, can cause a backwards incompatibility, is not designed correctly.
* I don't remember off-hand a case where we broke someone by adding new things to ohai. But it's a constant source of stress in ohai code reviews.
* There are plenty of cases where this is a newbie problem, though. A new user sets an attribute that is already set by some ohai plugin they didn't know existed. The user then struggles to debug why they get some strange value for their attribute, eventually writing `node.override["my_thing"] = "my value"` immediately above where they use the attribute and it still doesn't work, until someone tells them that some ohai plugin sets this value and they need to pick a different name.
* It's just confusing to have attributes with different semantics (read-only, set by the system vs. read-write, set by the user) accessed by a single API. It implies an equivalence that doesn't exist.
* ohai data doesn't benefit from attributes behavior (multiple points of customization) because you can never customize it except by patching ohai.