I think the type in SpecificRecord and elsewhere has to be a List<T> instead of Collection<T> in order to guarantee ordering, and that methods like add() actually append to the list. If someone sets a field to an arbitrary collection, say a Set, then that gets passed on to other code that expects add() to function like an array, there will be surprises.
I believe that at minimum, GenericDatumReader.newArray() and addToArray() need to check for instanceof List instead of Collection, and if a non-list Collection, create a new GenericArray from a non-list Collection.
We should be able to take in any Collection to initialize an inner List; if there was a getter/setter style for SpecificRecord then the setter could take Collection<T> and the getter return List<T>, but with raw public member variables our hands are tied.
Alternatively, a simple thing to do is just change Collection to List in this patch – clients can always use new ArrayList(Collection c);
As much as I like this feature and think that making such changes should be done sooner rather than later, I suspect we will be changing these APIs more in the future and it might be less painful to batch them all up. Specifically, I'm thinking about changes to the generated classes such as using getters/setters to hide the internal representation of the data.