Describe your Issue

Due to eager binding of number type when reading JsonNode -- basically, decision must be made between reading:

1. Slightly faster, but potentially lossy Double vs
2. Bit slower but unlimited range/precision BigDecimal

(to get either DoubleNode or BigDecimalNode)

there are cases where common buffering use cases expose unexpected precision loss -- particular since by default Double is used. See, for example:

FasterXML/jackson-modules-java8#326

This behavior can be changed via DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS, but that is global setting. Instead, it would perhaps make sense to add a JsonNodeFeature which would only affect JsonNode reading, but would have precedence over DeserializationFeature.

I haven't thought this fully through wrt implementation but this seems like potentially useful thing to have.