Presumably GIMME_V is also a complex macro in 5.8.x, yet there's no such problem there.

It's not the complexity per se, but rather the specifics of what happens in detail. And just because it works with 5.8 does not necessarily imply it would have to work with 5.10, too. A minor change could be sufficient to cause different behaviour.

For one, compilers generate machine code based on implicit assumptions with respect to their inner workings (like widths of data types, alignment of fields within structs, etc.). If you mix machine code compiled with different compilers, the underlying assumptions may or may not match. Often, there is no problem, but there's no guarantees whatsoever.  OTOH, the same compiler can also generate different code depending on the build environment, such as compiler options, contents of header files involved, etc. — which would explain why when recompiling with the same compiler, but in the context of a different Perl (MinGW-built Perl vs. default ActivePerl), everything is sweet.

I bet that if you use a debugger to step through the machine code behind that GIMME_V macro, you'll figure out why it evaluates to 0x80 (== G_VOID, btw), instead of 1 (== G_ARRAY), in the problem case.