This is actually the topic of an upcoming blog post, but in short Blink offers two ways of handling extensions to existing messages.
First, there is the built-in support for unsolicited message extensions. Any message can carry an extra sequence of Blink objects. This makes it possible to convey new content to and through an otherwise closed system without modification. However, this approach is probably best suited for ad-hoc updates and annotation-style content.
The other way, which deals with the more important subject of schema evolution, relies on what we refer to as a two-schema approach. One schema is the (compiletime) schema used when implementing the application/component and the other schema is the (runtime) schema for the messages actually transmitted. Knowing the two schemas, the encoders and decoders will then deal with the addition and removal of fields and potentially type conversions.
The two-schema approach is to some extent used in the jblink implementation where the compiletime schema is implicit in the structure of the objects being populated. If a new field appears in the runtime schema, a decoder will just read and throw away the result since there is no matching field in the target object. A more elaborated implementation could opt to store such extra fields in an appendix making them dynamically accessible.
/D