Well I'll ask you... given a generically stated math problem such as "

", what is the result type? Because that is fundamentally the problem we have to resolve. You can't do it. Too much depends on information we don't have.

And your CoalescingType contract misses most of it still. Just take your com.ibm.icu.math.BigDecimal usage. The answer is much different if the com.ibm.icu.math.BigDecimal is used as the denominator of a division versus being used as the nominator versus being an operand in a multiplication versus ...

The only real option I see here is a pluggable strategy to determine the result type of a BinaryArithmeticOperatorNode. For cases where the result type is the same as one of the operand types I could see a partial solution where we simply use the operand type (as opposed to one of the StandardBasicTypes constants). But again, that's just a partial solution. We might even expand that to a new contract for Type similar to your CoalescingType but much more expressive and useable, e.g.:

interface BinaryArithmeticResultTypeResolver {
    /**
     * Used to resolve blah blah blah
     *
     * @param operation The arithmetic operation being performed
     * @param isLeftHandOperand Is this type from the left-hand-side expression?
     * @param otherType The Type of the other operand.
     */
    Type resolveBinaryArithmeticResultType(
            Operation operation,
            boolean isLeftHandOperand,
            Type otherType);
}

Otherwise, I'm all ears for your better proposal...