When using an entity reference autocomplete field on a webform for a single taxonomy vocabulary bundle with the option to auto-create entities if they do not exist, submitting the form with a non-existent term value produces a validation error stating There are no taxonomy terms matching "[value]".
Screenshots attached showing the relevant webform field configuration and the validation error for clarity.
I have narrowed this down to the Drupal\webform\Plugin\WebformElement\EntityAutocomplete class in src/Plugin/WebformElement/EntityAutocomplete.php. The issue is in the prepare method, which starts on line 99 in Webform versions 6.2.8 as well as the 6.3.x branch.
On line 108, the element will set the $element['#autocreate']['bundle'] value required for the core field's auto-create function to work, but ONLY if both $element['#selection_settings']['auto_create'] AND $element['#selection_settings']['auto_create_bundle'] are not empty. The problem here is that when only one target bundle is selected in the Webform element's configuration UI, the field for selecting the bundle to use for auto-creation is hidden and no value is saved with the configuration.
Upon reviewing the core entity autocomplete field's code for when using that widget type on, say, a node entity, it figures out which bundle to auto-create when only one is selected, otherwise expecting one to be specified. However, the Webform element provides no similar code, so there's no bundle set and therefore it does not add the $element['#autocreate'] settings to the field at all. As a result, it doesn't try to auto-create the non-existent entity.
One solution I propose would be to update the code in the prepare method to set the auto create bundle value when auto create is not empty but auto create bundle IS empty.
Another solution would be to update the code for saving the field configuration so that it automatically sets and stores the auto create bundle value when only one target bundle is selected for the reference field.
To me the former seems more straightforward and is a simpler change to the code.
Active
6.2
Code
I've provided a second merge request to re-roll the same fix onto the 6.3.x branch.