Originally reported at the end of the description in MDL-83563, but was not addressed in that issue. Discovered during tech. discovery on MDL-85358.

Note: The 'in'-comparison currently behaves just like the 'eq'-comparison for multi-selects (i.e., the list of selected values must match the given list of values exactly). I would argue that it would make more sense to do the comparison separately for each selected element (i.e., each selected value must appear in the given list of values). This would mean that the 'in'-comparison succeeds if and only if the set of selected values is a subset of the given set of values. Otherwise, the 'in'-comparison doesn't serve any purpose in this situation.

Currently, if you want to set up the multiselect/autocomplete such that the inclusion of an option in the selected options (i.e. it's one of potentially many selected options) controls another form element with hideIf/disabledIf, you end up needing a multitude of hideIf rule declarations, covering all possible combinations of options, since it's implemented the same as 'eq'. This rapidly grows out of control.

This is a problem and it should be fixed. It's neither intuitive, nor correct for the multiselects/autocompletes, where it should be checking whether the selection is a subset of the rule values.

See also my comment here: https://tracker.moodle.org/browse/MDL-85358?focusedId=1158607&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1158607, which provides a branch with a demo form, highlighting the problem.

This currently blocks MDL-85359 in the LTI project.

Note: this will also impact admin settings which also uses a similar hideif rule for admin settings, which currently also behaves like 'eq'.