So, to clarify a bit. ZMTPSession currently has 3 conceptually distinct uses. It is used by the calling code to configure a connection (setting up truncation limit and local identity), it is used by the library code to communicate certain data about the connection to the caller (such as remote identity) and it is used internally in the library to propagate connection state between various pieces of code.

Having thought some more about it, now that ZMTPSession becomes more of a configuration bean than it was initially, I think it is kind of bad that ZMTPSession even has a version field, as it would hint to the casual library user that this was the way to configure version capabilities of a ZMTP connection (which it is not, this is currently specified using two different ZMTP*Codec classes)

There are also two distinct but related version properties of a socket/connection. There is the desired version, there is the negotiated (actual) version, in case of an interoperability downgrade.

All in all, I think that it would be a bad idea to get even more of the third use case (state propagation between various parts of the library code) into ZMTPSession, especially when it's a public interface alongside with properties that the library users are encouraged to tweak.

I think there are a few ways to move forward from here:
- We refactor the code to get rid of the multiple uses (and confusing semantics) of ZMTPSession. I'd rather avoid this, as it would draw out the process of getting this merged even longer.
- We keep the constructor parameters as is, since this in my opinion is a perfectly valid way of propagating internal state between different parts of the library code
- I STFU, make the change you ask for, and get even more cruft with unclear semantics in ZMTPSession to clean up later.