Thank you for taking the time to report a problem with the package.
This problem may have been already fixed by a previous change that
is in the CVS of the package. Please log into CVS with:
cvs -d :pserver:cvsread@cvs.php.net:/repository login
and check out the CVS repository of this package and upgrade
cvs -d :pserver:cvsread@cvs.php.net:/repository co pear/Math_BigInteger
pear upgrade pear/Math_BigInteger/package2.xml
or
pear upgrade pear/Math_BigInteger/package.xml
If you are able to reproduce the bug with the latest CVS,
please change the status back to "Open".
Again, thank you for your continued support of PEAR.
You actually provided enough information in your first post. What I meant when I selected the "Not enough info" option was that I was hoping you could confirm whether or not the fix I proposed worked. I didn't realize it'd auto-add two extra paragraphs to my comments.
Anyway, I've committed what I believe is the solution to CVS. If you could confirm that that works (by downloading the latest CVS), that'd be great! :)
I also wasn't able to duplicate your problem exactly. MATH_BIGINTEGER_MODE_INTERNAL gave me erroneous output, but it didn't give me 0. This is why I was sorta hoping you could confirm the fix before I committed it.

I can also reproduce this. The fix did not solve it. Changing MATH_BIGINTEGER_MONTGOMERY in this fragment:
if ( $n->value[0] & 1 ) {
return $this->_slidingWindow($e, $n, MATH_BIGINTEGER_MONTGOMERY);
}
to either MATH_BIGINTEGER_BARRETT or MATH_BIGINTEGER_CLASSIC fixes the problem, though.

The problem seems to come from _modInverse67108864(). This function returns 0 with argument 50019009 instead of the proper value which is 55290559. The cause appears to be related to some kind of overflow in the last step, namely this line:
$result = ($result * (2 - ((($x & 0x3FFFFFF) * $result) & 0x3FFFFFF))) & 0x3FFFFFF;
Adding an extra modulus after the subtraction step seems to solve the problem for this case:
$result = ($result * ((2 - ((($x & 0x3FFFFFF) * $result) & 0x3FFFFFF)) & 0x3FFFFFF)) & 0x3FFFFFF; // x^-1 mod 2^26
I can't promise it will work for all cases, though. Working that close to the numerical limits can trigger compiler bugs, inconsistent (even if standards-compliant) behaviour, etc. (indeed the fact that Jim can't reproduce this bug may be related to the compiler used for building PHP).

This bug has been fixed in CVS.
If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET).
If this was a problem with the pear.php.net website, the change should be live shortly.
Otherwise, the fix will appear in the package's next release.
Thank you for the report and for helping us make PEAR better.
Well, based on some emails that I and Pedro Gimeno exchanged, I think this is fixed. The comments of the latest CVS elaborate (specifically, the comments of the _modInverse67... function).