question

This is working as intended

That's the short answer. When back orders are reevaluated the entries are considered one at a time starting at the top. The back orders are sorted according to the Back Order Queue Strategy and then the best back order that wants the entry gets fulfilled. Notice, that the back orders are being sorted, not the entries. And the back orders can be sorted in a different order for each entry if the queue strategy sorts based off some characteristic of the entry (like the distance field). This behavior works for the majority of models, except for situations like yours where you suddenly make a bunch of entries available at once.

The only way to get around this is previous to 18.2 is to control the list more tightly. Either don't push entries on the list until they're actually ready to be pulled, or find a way to not create a back order.

18.2 lets you choose the behavior you want

You're not the first person to run into this issue and in 18.2 we added a "Sort Back Orders Before Evaluating Entries" checkbox to the List properties. Checking this box will get you the behavior you want. Instead of considering each entry, the back orders are sorted once and then each back order is considered. If you can update to 18.2, I would recommend it and then you just need to check the box.

Here's the documentation of that checkbox in 18.2 (note that leaving the box unchecked is how the list worked before 18.2):

Sort Back Orders Before Evaluating Entries

This setting determines how back orders will be sorted when they are reevaluated for all entries on the list. The default is not checked. Here the list will iterate through each entry on the list, sort back orders associated with that specific entry, then match the highest priority back order to that entry. Alternately, when this box is checked, the list will sort the back orders once, then iterate through each back order and fulfill that back order based on its pull query.

Leave this Box Unchecked If the Back Order Queue Strategy Relies on Entry-Dependent Fields

When this box is checked you are not allowed to include anything in the back order queue strategy that accesses data associated with a list entry. Since the list sorts back orders first for all entries, there is no single entry to compare back orders against.

As an example, let's say you are simulating a list of nurses, and back orders for nurses represent the patients who are requesting them. When one or more nurses become available, they may want to sort the requesting patients based on the distance from the nurse to the patient. Such a back order queue strategy might be: ORDER BY distance. In this case the distance field needs both a nurse (an entry) and a patient (a back order) in order to calculate the distance between the two. Here you want the list to go through each newly available nurse, and sort back orders (the requesting patients) by the distance from the nurse to the patient. This desired functionality is enabled when this checkbox is unchecked.

Check this Box If the Pull Query ORDER BY Clause Should Still Be Used When Multiple Entries Become Available at the Same Time

When this box is checked, the list will sort the set of back orders once, then go through each back order and attempt to fulfill it based on its pull query. This scenario allows for the back order's pull query to still be in effect when multiple entries become available at the same time. In going through each back order, the list will evaluate the back order against all of the available entries, meaning the back order pull query's ORDER BY clause will take effect, and available entries will be sorted accordingly.