FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key
generation algorithm, and have domain parameters which look identical, however
there are two subtle differences between them, one of which is really annoying.

The annoying difference is that when writing the domain parameters, the order
of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain
parameters are written (p, q, g), exactly the same domain parameters when
viewed as X9.42 values are written (p, g, q).  This isn't helped by the fact
that in many fonts lowercase q and g look very similar.  Apart from the fact
that it's a booby-trap for implementors, it also means that if the domain
parameters are identified in the traditional way (SHA-1 hash), identical
parameters will appear to be different depending on whether you're interpreting
them as DSA/KEA or DH parameters.

The second difference is in the allowed range for x:

  FIPS 186: 0 < x < q (ie x = 1...q-1)
  X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2)

This looks like a transcription error from FIPS 186, given that using any
x < ~2^160 is unsound I can't see why there'd be any difference between 1 and 2
as a lower bound.

Perhaps new RFC's which cover this (eg son-of-RFC2459) could include warnings
to the effect that although the parameters are the same internally, their
external representations differ.

Does anyone know why X9.42 decided to reverse the parameter order?

(The motivation for this post is that ages ago I solved the problem of the
 reversed parameters by swapping the pointers for the X9.42 g and q values so
 they were read and written in the correct order, recently I was looking
 through the code and wondered why it was working fine for both interpretations
 of parameter ordering.  There's now a big comment block by the code explaining
 the Bug which Isn't)
 
Peter.