Let's take the case of a SharePoint list of products. This list contains a yes/no column called 'Active', which stores whether the product is an active product.
The following, syntactically correct formula, would not return any records.
What were the workarounds?
The first common workaround was to filter by the number 1 or 0, rather than a Boolean true/false value.
The following formula would correctly return the active products. However, the designer would show a warning because the formula compares a Boolean to a number.
A second, more effective workaround, was to not include the equality operator in the condition. This formula would correctly return active products.
The problem here was that appending additional conditions would result in expressions that were not delegable, even although the target column types and operators were delegable.
The third workaround was to avoid the use of yes/no columns, and to use a text column to store the text 'yes' or 'no'. This wasn't ideal because it wasn't applicable against existing lists with existing yes/no columns. Also,
this solution made it more difficult to build forms with toggle/checkbox controls, because the default control type for a card would be a text input control.
Why was this bug such a problem?
Whilst the workarounds above were helpful, this bug made it difficult to filter SharePoint lists effectively by yes/no columns.
It was a struggle to construct multiple filter conditions that included yes/no columns, in a delegable way. Additionally, it was difficult to filter yes/no columns by variables or other control values, particularly when using the workaround that excluded the equalities (=) operator.