> I might be naive in thinking that protocol.version could be removed or > redefined at our discretion just because it's marked as "experimental". Well the redefinition might very well occur, when we now say "set to v1 to test v1 and fallback to v0 otherwise", but long term we want a white or black list or some other protocol selection strategy encoded in this configuration (we would not want to introduce yet another config to work around the initial "failed experiment", would we?) And hence I would be careful how we define the meaning of protocol.version now. For example we could instead now claim "protocol.version is a whitelist of protocol versions, order is not specified. The only guarantee we're willing to give is that no protocol is used that is not on the list". Later we may want to either add another variable '.versionSelectionStrategy' that helps out there or we'd just say protocol.version tries to select the leftmost (first) protocol that both ends support. All I was trying to say initially is that "we may try (one of) protocol.version, but fall back to whatever (currently v0)" is too broad. We'd need to redefine it shortly in the foreseeable future already.