This is not an issue with the release of this feature.
You’re running into a race condition where all the workflows are editing the list at the same time (“add” is misleading because the action it’s still editing the whole list via API). The only reason you did not run into this issue before was that the performance was just slow enough that the workflows ran with enough time between them not to conflict with each other.
To solve this, you either need to enforce an interval long enough to eliminate the race condition (make the workflow on a list intentionally and predictably slower), or you need to set up something that waits until all items are created, then sets the list one time in the end.
I’ve accomplished this before by adding a “last item” parameter, with the logic “If This Item is List of Item’s Last Item”. Then, in the workflow, just add a step to schedule a final workflow or custom event a second later to set the list based on a search. I would have it schedule it out a second (as another workflow or customer event), as opposed to just setting the list in the last workflow, as there still might not have been enough time by the last workflow for all items to appear in a search.
The irony here, is that this new release is literally so good it’s causing issues. The only way to avoid this would have been not to make the improvement. It’s an unfortunate but unavoidable problem that would never have been caught with any amount of prior testing.