This behaviour was deliberate:  since the standard doesn't cover three-
argument pow, I more-or-less made up my own rules here.  :)

In this case, I (somewhat arbitrarily) decided that to ensure that any 
possible pow(a, b, m) result could be represented, m should be strictly 
less than 10**current_precision.  In general, you'd expect to make lots
of pow(a, b, m) calls with the same m and differing a and b;  it seems 
less error-prone to have them all these calls fail/pass together than 
have those with small results pass, and those with larger results fail.

Not that I expect there's a single person on this planet who's using 
three-argument pow with the Decimal type.  :)

Looking back at this, I'm not quite sure why I chose 'strictly less 
than' rather than 'less than or equal to'.