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 ...

I am not sure I understand all the different use cases. In our specific case we would prefer the icu.math.BigDecimal to always be determined as the result type, regardless of the arithmetic operation or whether it's a nominator or a denominator. I don't really see why would someone want a different result type. BigDecimal and a Double could be the case to consider, but we don't have this use case in practice.

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.:

When both operands are of the same custom type the result is already resolved to this custom type in current implementation. For other cases we'd like to have a pluggable strategy or a new contract for Type. A pluggable strategy might be a better choice since it's then for the hosting application to setup this custom resolver in one place to handle custom type resolution. A new contract for Type is more ambitious and I am not sure it's worth the trouble. In any case our implementation would be trivial and the interface similar to what you propose would work well enough for us.