> Perhaps, the stringable concept should be moved to GenericData instead?
Perhaps, but that would be much more incompatible. Adding stringables to specific permitted some things to work (e.g., BigInteger) that used to fail, which is not 100% compatible, but largely. With generic, it would cause schemas that were readable before to change the representation they're read into. So such a change, if desired, would need to go into 1.8.0.
Is this desired? With generic, any schema can be read into a closed set of classes. With extensible stringables this would no longer be true. That makes it harder to write programs that can generically process data of any schema.
> is there a reason for Avro integer to accept any Java Number, and silently convert/truncate them to Integer, while other Avro primitive types will require an exact class match (eg. Avro long will require Java Long, and not accept Java Integer).
In reflect, an int schema is used to handle Java's Byte, Character and Short types too. Is that what you're referring to?