We should definitely consider this so that such extensions are possible.
As for the use case above, the latest version of Avro uses Velocity templates for SpecificRecord generation – so you could generate classes with all the getter/setters you want. One of the items I wanted to get to was to experiment with ways to remove the boxing/unboxing overhead for these objects. IndexedRecord neatly simplifies access to fields but has the boxing overhead.
Are you willing to share or contribute what you have done so far?
There are some approaches I have considered. I was going to take a stab at 'merging' the Reflect and Specific API by way of annotations to get rid of this overhead – essentially have the code gen create annotated classes that specified how the schema maps to the fields – and have reflect consume those. Later down the road, Reflect could use cgilib and/or asm to create serialization / deserialization classes on the fly that would be compiled to very very efficient code and be faster than the current Specific API.
Lastly, note that autoboxing/unboxing in some cases has become 'free' on the latest Sun JVM with '-XX:+UseEscapeAnalysis' on. This will default to on in a later JVM release. If the object is boxed manually (using new Integer(), not Integer.valueOf()) and the object does not escape a small enough code block, the JVM will avoid object creation entirely. This can help some of the IndexedRecord API usage.