It appears that this is a very old bug. Behind the scenes, the original one-liner is equivalent to this:
----------------
use strict;
use warnings;
use 5.014;
use Math::BigInt;
use Math::BigInt::Lite;
my $a = Math::BigInt::Lite -> new(8267);
my $b = Math::BigInt -> new(927208363107752634625923);
say Math::BigInt::bgcd($a, $b);
----------------
Math::BigInt::bgcd() first uses objectify() to ensure that all operands are objects() of the desired ("goal") class. In this case, objectify() is not given a desired class explicitly, so it assumes that the desired class is the class of the first operand, which is Math::BigInt::Lite.
objectify() sets out to convert all the operands to Math::BigInt::Lite objects, but it accepts objects of classes that Math::BigInt::Lite may be upgraded to, i.e., Math::BigInt. The operand $a already is a Math::BigInt::Lite, and $b is a Math::BigInt, so objectify() does nothing to any of the operands. The operands are then passed back to Math::BigInt::bgcd().
So Math::BigInt::bgcd() is given a Math::BigInt::Lite ($a) and a Math::BigInt ($b), but Math::BigInt::bgcd() can't handle Math::BigInt::Lite objects, so the code fails.
The solution seems to be to improve objectify() so it becomes better at guessing what the desired class is.
One solution might be to use caller() to determine who called objectify(). A better solution, in my opinion, also happens to be a goal of of mine: to change all calls to objectify() into methods calls. That way, objectify() always knows the desired class.
