Merge elements in an array
comparative-review:
In both variants, both "traversing indices" get compared to their (respective upper) limit in each traversal of the "proper merge loop".
While "the copy2res-loops" should never execute in merge1, the "res-index" gets compared to its limit right from the start.
In merge2, the "proper merge loop" isn't traversed as often.
Exactly one of the copy2res-loops should be traversed for the same total.

remarks:  


merge() isn't doc-commented.
the comments for start&amp;mid might as well be @params,
index of mid looks off,
all three may be final.  
Both subarrays include their start - excluding end would be consistent.  
I don't get the inversion counting - lack of documentation doesn't help.


Speed-up:  


beware memory hierarchy effects
old school complexity analysis assumes uniform memory access time - far from what I'd want to pay and wait for.
don't copy back and fro. Use the auxiliary sequence as the/one source for the next pass.
don't convert between Integer and int time and again.  
when using Lists, avoid relying on the "random accessors" to be fast
(implementing RandomAccess is a hint - read backwards, its doc recommends to "always")
use ListIterators to iterate Lists  (note how they (optionally) support set(newValue))
don't time-consumingly ponder/implement variants unless you


established it matters
fixed a measure for good enough

converting to arrays and never looking back (with the possible exception of a terminating conversion/copy back) is an option promising sequential storage and allowing bulk operations. With Lists, operations on sublists may be more efficient.  
Most JREs allow a peek at their implementation (have a look at java.util.Arrays, too).