As a result of experimentation with AVISynth and the assistance of some very talented people on the Doom9 forums, I've uncovered an incompatibility with the Intel Media API v1.7. It would seem that part of the movie "Pacific Rim" simply doesn't work with this version, but only if you're using the 3D disc as the source (the 2D disc appears to work just fine). There are at least two sections where attempting to use the Intel Media API results in frames being corrupted and lost, each and every time you attempt to decode them.
Some examples are available here: https://mega.co.nz/#!co8BzRpL!qXoCWL-vKmFry2RmLe2G1P3oHn0le6NZJ7NnjAMJOck
Note that these have been extracted from the full stream with tools that are not entirely MVC aware, however the AVC stream alone demonstrates the issue. Included are both source, raw streams (pre-combined AVC/MVC streams) and the results I get when processing them using the Intel Media API to decode.
That said, another programmer on the same forum has inadvertently found the solution: using API v1.8, at least in short tests (I'm confirming this presently with a more thorough test, but the results of that are several hours away), gives perfect output. This would be fine as an alternative if not for two fairly important (in my mind) details: v1.8 decoding cannot presently be hardware accelerated, and actually enabling v1.8 requires a very specific command line. In fact, the only way I've found to get v1.8 to work is to use Software mode ("SW" flag) and either D3D or System surfaces - D3D11 surfaces revert to v1.7 even in SW mode - meaning anything which does not specify these two conditions while having access to "higher" sets will use v1.7 and ultimately produce the errors; and even when these flags are specified I have seen it still fall back to v1.7.
I realise this may not seem urgent as I have only identified one stream presenting the error (out of the 53 I have so far tested), so it is fairly isolated. A fix has obviously already been implemented in the v1.8 API as well. However, I still believe that back-porting the fix to v1.7 is a good idea as most, if not all software which currently uses QuickSync decoding still depend heavily on v1.7.