Selection labels incorrect on configure / confirm form when new entities were created after view was displayed

Thanks for reporting, confirmed this bug occurs.

The source of it is in Drupal\views_bulk_operations\Plugin\views\field\ViewsBulkOperationsBulkForm::viewsFormSubmit(), where we update list data with the current form selection.

Updated title to reflect the issue.

I created a patch to fix this by getting the checked values using the getUserInput() function instead of getValue(). Also, I removed the usage of row indexes for getting the labels of the checked elements because if a new node is created (or someone deletes one), the nodes' actual row index in the view could change. Instead, I modified the bulk form key generating to include the entity label, too. And later it is retrieved from there.

There is one problem I encountered with this approach with views with no exposed filters, and no pagers (So every result appears on one page). I'll try to explain:
1. I select 2 elements on the list, let's say their labels in the rows are "A" and "B".
2. I select an action which opens a configuration form.
3. Now I don't submit it, I changed my mind and I go back to the view.
4. I click to Cancel, it takes me back to the view.
5. I deselect the "A", so now I want to take actions on "B" only.
6. Now when I submit it, in the code I could get only the selected "B" element from the form state. Therefore, I found no way to check if "A" was unchecked by the user on this page, or is it still checked on the other pages of the view (not without extra checking how many pages does this view result have). Of course, I cannot use their row index, because that could vary.
This doesn't affect the views that have results in multiple pages because there appears to be a 'multipage' form element, and there are AJAX calls to update the list data when something is checked/unchecked. Views with one page results don't have these AJAX calls.

To solve this problem I added an extra if statement to the patch:

        if (!isset($form['header'][$this->options['id']]['multipage'])) {
          $this->tempStoreData['list'] = [];
        }

So if that 'multipage' form element doesn't exists, then every time the view form is submitted, I empty the list data first and after that I add the checked form elements to it. This will eliminate every previously checked elements that are not selected anymore (only for single page views, where elements cannot be selected on other pages). There's surely a better solution for this. Maybe using the same AJAX calls for views with single page results? What do you think?

Is this also an issue/risk in D7?

Removing patch duplicate from display.

This was fixed in #3119307. Upgrade to 8.x-3.10 or newer.