The first part is that it's really bad to reuse an IV with the same GCM
key.

The way this is addressed in FIPS 140-2 is by having some conditions
that need to be met when a GCM implementation is certified and also by
adding some guidance to the security policy about how the GCM
implementation can be used. The long and short of this is that a GCM IV
must be created within the boundary of the module, the intention of this
seems to be that the certifying lab should be able to verify that the IV
creation, if being generated using a sequential generator, will never
repeat.

The second part is that TLS provides a mechanism for generating IVs so
they don't repeat, however in most worlds this is implemented in the
protocol layer, which is outside the boundary of the module.

The result of this is that generally there's no way of certifying the
generator, without moving the whole TLS implementation to within the
boundary. You can't just do what is done with the JSSE Provider FIPS
mode, where you can justify the claim of compliance on the basis that
everything related to the crypto is outsourced to the underlying JCE
provider (which presumably is FIPS certified) - the GCM IV is calculated
too high up.

Consequently at the moment most of us can't support GCM as we can't
generate the IV in a manner that's within the FIPS guidelines. Getting
something changed once you certify a module is expensive and time
consuming (for everyone) so for those of us with layered implementations
such as you have in Java and C#, moving the TLS implementation into the
boundary of a FIPS module would be the path to insanity - you only have
to look at some of the issues which have shown up in TLS in the last
couple of years. We've also all just started on the adventure that is
TLS 1.3 as well, it is not hard to see the fun that would cause.

NIST have revised the guidance on this a couple of times now, we think
in the most recent revision the guidance is finally where we can provide
a mechanism within the module boundary which can be used by our TLS API
safely, while still providing a testing lab with the ability to ensure
we're "walking the talk". We're going to include this in 1.0.2, but for
now 1.0.1 and 1.0.0 are not capable of supporting GCM with the JSSE.