why cant it be multiple?

you don't choose Yes and No And sUse plugin together.

We should have a field where we list usergroups ids and no default value: look at user field

@infograf768 the label refers to the field not the select tag next to it, so yes you can have multiple usergroups (it's not multiple values like: yes, no,none)

EDIT:
In fact it is only the DEFAULT VALUE which should be changed as done in User field.
It indeed can be multiple.

And in this case (when corrected as User), and looking at the code, Multiple is useless. It is no use in the params in the plugin as in the specific created field.

We should have instead of the 2 fields, something like

<?xml version="1.0" encoding="utf-8"?>
<form>
	<field
		name="default_value"
		type="textarea"
		filter="raw"
		label="PLG_FIELDS_USERGROUPS_DEFAULT_VALUE_LABEL"
		description="PLG_FIELDS_USERGROUPS_DEFAULT_VALUE_DESC"
	/>
</form>

and

PLG_FIELDS_USERGROUPS_DEFAULT_VALUE_LABEL="Default Usergroups"
PLG_FIELDS_USERGROUPS_DEFAULT_VALUE_DESC="A comma separated list of usergroups ids."

Multiple refers to the USER selecting multiple usergroups when this field is displayed

ok. now what is the default value for?

The default value preselects some ustegroups when the field is the first time visible when editing an article. If the field got emptied on an article save, then it reverts to the default value. Same behavior as everywhere in Joomla.

Ok, this is what I found.
If one usergroup id is entered in default value, then the chosen usergroup is indeed showing whether Multiple is set to Yes or No.

So, one can't enter in the default value more than one id.

My suggestion is to use specific strings for the default value explaining this.

@laoneo
Is it worth adding a custom Default Value with a tip to explain what that field may do?

I guess it is not a bad idea. Then another question pops up. Should we then build in better support to override the default label and description, otherwise we always need to define the whole default field as in #14679? When we want to change some parameters in that field, then we need also update all the overrides as well.

If we have time for that, why not indeed.
if not, let's just do it the same way you did for the User field. In both cases, we will need at least one more language string.

Please check #14793 for a label and description override functionality.

Guess we can close this one then.

Closed as we have a patch.