Sorry for the delay. Here are my thoughts:
1. For the Dynamic use case, at some point we'll want an idiomatic Scala API, which leverages Scala collections, embraces immutability, and so forth. The patch above does not address this use case.
2. For the Code First use case, macros can be used to generate a compile-time schema from Scala classes (of course, it's possible to do this using reflection, as well, but you risk the possibility of blowing up at runtime if you can't handle the mapping between Scala and Avro). The patch above does not address this use case.
3. For the Schema First use case, I think code generation is acceptable for some scenarios. When you have to support multiple conflicting schemas, it becomes easier to manage migration in code with user-defined classes (and, perhaps, a compile-time mapping between those classes and Avro schemas). However, for the simple case where there exists only one schema or multiple compatible schemas, some developers may prefer just to generate the case classes using code similar to the above patch.
As for comment about the patch specifically:
1. I would prefer if you could decode into immutable classes directly.
2. The union type should be a sealed trait, not an abstract class, and commonalities between the case classes should be factored out into the trait.
3. Consider an option to generate pimps for the types so users can "add" their own methods without having to actually edit the code.