Assuming that enqueue operations would speed them up, things only really get interesting when you have 2 operations that can be performed completely in parallel.

for example:
C: -> F: while also doing D: -> G:

Now given a list of drive pairs (from and to), and costs of operation (file size combined with drive speed), what you get looks like a weighted graph. And then you have to pick the sequence of all edges that optimizes something to the effect of:

# warning: untested!

use List::Util 'sum';
use Math::Combinatorics 'combine';

# @edges is the sequence of operations
# edge_value and has_common_drive are left as an excercise to the impl
+ementer

my %seen = ();
my $fitness =
  sum(
      # sum up operations until blocking
      map { sum(
        map { edge_value($_) }
        @edges[ $_->[0] .. $_->[1] - 1 ]
           ) }

      # take only the first collision after an operation
      grep {not $seen{$_->[0]}++}

      # sort collisions by distance between
      sort { $a->[1] - $a->[0]
       <=>
         $b->[1] - $b->[0]
     }

      # find colliding operations
      grep { has_common_drive( @{$edges}[@$_] ) }

      # all combinations of operations
      combine(2, 0..$#edges)
     );
[download]

I'm not inclined to prove it, but your problem seems to be at least NP complete.

And then you have to consider that you would have to re-evaluate your moving strategy whenever a new edge is added to your graph (whenever you enqueue a new operation).

Don't forget that operations on the same file *MUST* occur in FIFO order when at least one of them is a write. This is likely uncommon, but it is a critical error to do operations otherwise.

The only reasonable solution is to apply heuristics and get a "close enough" answer. But what is "close enough". And how hard is it going to be to get there? Too hard and not worth it IMHO.

In short, I don't think that writing a queue for this would be easy if you hope to get anything close to optimal.