I can reproduce the behaviour that you're seeing, I'm trying to trace it down to a bug or something missing in the custom adapter.

I upgraded your jsfiddle to use the latest release (4.1.0-beta) and the issue still exists. If I log the value of each result when it is displayed, I can see a few interesting things:

1. When the results are selected, the <option> element is properly injected but it isn't being associated with the data option as the element property
2. As a result of the above issue, the selected property is instead being set on the data object to true

And when you try to unselect it

1. The previously created <option> still persists (as expected) but is not unselected (unexpected)
2. The selected property that was set on the data object is set to false
3. An unselect event is properly triggered but that is also not attached to the <option> but it does have the modified selected property

And if you try to select it again

1. The selected property that is set on the data object continues to show as false

Figured out the issue.

The id property on data objects must be a string or it won't be able to match up with the <option> that is created (since <option>.value is always a string). This is why the element property isn't getting set as expected on the data object which leads to pretty much the rest of the issues we were seeing. Setting the id property to a string in the example jsfiddle solves these issues.

https://select2.org/data-sources/formats#automatic-string-casting

I'm still leaving this open since Select2 should handle this case and automatically cast it, but it looks like something isn't consistently doing that which is causing issues.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

The project maintainer deliberately chose to leave this open, so it should be left open

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@kevin-brown I was taking a look into this separately, and arrived at the same conclusion that the cache lookups for item data fail, resulting in a missing data.element property to apply effects to.

At least for a small repro case, there's an alternative solution that doesn't rely on id type-casting -- although it could be a bit hacky (particularly the assumption regarding a single option element per container?).

See: 8258567

Edit: update link to unbreak the commit hyperlink -- please note that it originated from a forked repository, though (not this repository)

See: 8258567

Sorry, ignore this attempt at a fix. I was testing it again using a hand-written select2 example, and this time it isn't working (the option elements do not exist), so I don't think it's valid.

Edit: update link to unbreak the commit hyperlink -- please note that it originated from a forked repository, though (not this repository)