Well, the real problem is that powmod doesn't really belong in the decimal module at all.  It's not a natural primitive arithmetic operation; it's certainly not naturally a floating-point operation; nothing like this appears in any floating-point standard that I'm aware of; and its (few) use cases are very different from typical decimal use cases.  I'd like to bet that it currently has precisely 0 users.  Trying to shoehorn powmod into the decimal module and make its semantics fit with the rest of the module seems a little pointless to me.

Really, what's the point of making any sort of attempt to preserve exponents in 3-argument pow?  Having the result exponent be 0 is clean, simple to understand, simple to implement (which your proposal is not), and matches the use-cases.  The restriction on the modulus also matches the use-cases:  typically, the modulus m is fixed, and you won't have any expectations about the output of powmod(a, b, m) except that you'll know the result is an integer in the range 0 <= x < m.  Having powmod reject m's for which only part of this range is representable avoids hard-to-find bugs where powmod(a, b, m) works for most values of a but then unexpectedly fails for some particular value of a because the result is just larger than can be represented.