A requirement is that the user cannot select a value different from those in the list, that is, when the user, for some reason, writes something in the multiselect, an error message is thrown, or else, that it does not allow the text input.
While disabling the "Allow free-form input" option allows input to the multiselect not to be counted as an item, it still allows free typing within the multiselect.
With this option selected, the user input inside the multiselect is not considered a list item until the user clicks on it in the dropdown list, meanwhile, the user input is not an item, so using an activity that iterates through the list is ruled out, since what the user writes isn't added to the list until they click.
So blocking the write input to prevent the user from typing something into the multiselect seems like the only viable thing to do, though I haven't found a way to do it.
***Edited by Moderator Marije to add Capability tags***
@EdgarIvanV I think it is better not to make more complex by bringing complexities to the OOTB control. More customization could bring responsives issues. As you identified disabling the "Allow free-form input" option will not allow user to type a value that doesn't exists and allow users to only type and select values which are in the list. What we did in our project is we educated end users that all the valid values will be displayed in the list and we would want you to type and select the values from the list. Users were perfectly fine with that. Think you also can educate the users with the same approach.