Support actually just replied to the bug report which would explain this:
The behavior you observed is a known issue with option sets where options sometimes use an underlying ID instead of the display value. The underlying ID is set when the option is first created, so there may be a discrepancy between the two if you have changed the display for the option. So, this may cause unexpected results when option sets are used within searches and in API calls.
You can determine the underlying ID of an option by exporting your application’s JSON, opening the resulting file in a text editor, and doing a text search for the display of the option (or something else that would identify it). The object containing that display will be the definition of the option. If this contains a “db_value” field, the value for that field is the underlying id. Otherwise, the underlying id is the key pointing to the option’s definition in the containing values object.