Problem description by using an example: 

Build graph: 

1─┐
│ │
▼ │
2 │
│ │
▼ │
3◄┘ 
 

1. The number represents the priority of the projects. 
2. The flags "Block build when upstream project is building" and "Block build when downstream project is building" are activated for all three projects. 

If I trigger project 1 I expect the following build order: 
1 -> 2 -> 3

I actually get the following build order: 
1 -> 3 -> 2 -> 3

Analysis: 

After looking at the code of Jenkins and PrioritySorter, I think I figured out what happens: 

After project 1 is done, both project 2 and project 3 enter the waitingList in the queue. The projects enter the waitingList based on their alphabetical order. In this example project 3 enters before project 2. Since the "block builds"-flags are activated, both projects are moved from the waitingList to the blockedProjects [^1]. 

The blockedProjects are now sorted by using FIFO. Since both projects are now blocked, the AbstractProject.getCauseOfBlockage() realizes that both projects are in a deadlock, and the first considered project (project 3 in this case), is being unblocked. The snapshot is immediately updated and thus the second project (project 2 in this case) remains on the blockedProject-Collection. 

Since there is now only one project on the buildables collection, sorting by the PrioritySorter has no effect and thus the project with the lower priority is being built before the project with the higher priority. 

[^1]: One might assume that only one project is moved to blockedProjects and the other is moved to buildables, but this isn't the case for the following reason: When Queue.maintain() checks if a project can be moved from the waitingList to buildable/blockedProjects, the snapshot of the queue has not yet been updated. Thus the first project is both in the waitingList and in the blockedProjects when the second project is checked.