[101011]

This ended up being the preferred pattern we moved into.

If, like us, you were passing the object between two applications, the owning API would serialize the enum value as a String value, then we had a client helper method that would parse the string value into an Optional enum value.

If the original service started transferring a new String object between services, it wouldn't break any downstream clients, because the clients would just end up with Optional empty

[janci]

How that works when you need to distinguish between "no value provided" and "a value that is not in the list" - in some applications they have different semantics.

[101011]

You could treat it as an nullable Option<SomeType>.

In practice, as it relates to enums, I don't usually see 'no value provided' as a frequently used case - it's more likely that 'no value provided' maps to a more informative 'enum' value