I think there are multiple concerns here, and they need to be analyzed separately -- they don't converge to the same solution: - Naming: "Other" should probabl

I think there are multiple concerns here, and they need to be analyzed separately -- they don't converge to the same solution: - Naming: "Other" should probably be called "Unrecognized" in these situations. Then users understand that members may not be mutually exclusive. - ABI: If you need ABI compatibility, the constraint you have is "don't change the meanings of values or members", which is somewhat stronger. The practical implication is that if you do need to have an Other value, its value should be something out of range of possible future values. - Protocol updates: If you can atomically update all the places where the enum is used, then there's no inherent need to avoid Other values. Instead, you can use compile-time techniques (exhaustive switch statements, compiler warnings, temporarily removing the Other member, grep, clang-query, etc.) to find and update the usage sites at compile time. This requires being a little disciplined in how you use the enum during development, but it's doable. - Distributed code: If you don't have control over all the code using your enum might, then you must avoid an Other value, unless you can somehow ensure out-of-band that users have updated their code.