I see your point for allowing more convenient to write code using methods with BigInteger by not having to write out any explicit converting at the call site. My concern is that it is harder to read without possible confusion.
Under the saying of “scripture languages should cater to the writers of their source code while application languages should cater to the readers of their source code” I would be concerned about the loss of readability outside of the simple examples.
True, you must add explicit convertibility to an object, but when I say implicitly conversation I mean from the callers side. When a caller used someInt(1) they are calling a method with an implicit conversion that is explicitly defined elsewhere.
Another potential complication is method resolution. Even if we make a rule that calls that don’t require conversion always resolve before ones that require conversion, there still remains a big mess every time an API adds an overloaded method since every overloaded method has the potential to be a breaking addition.
For an example for a confusing conversions–which was removed–look at how the conversation for Double.toShort() was deprecated because it performs conversion without being clear what should happen for the caller.
For breaking smart casts, I can imagine smart casts still working as if the object is some kind of intersection type of all it’s conversions–which would be pretty messy and still soft break smart casting for a lot of cases since we aren’t really learning anything about the cast object itself from a successful cast.