I think this may bring a misunderstanding to some implementer of the protocol. i.e. He may wright a code like this to save the work to interpret the message length field (this is a backend side code).
if (message_char == 'Z') { read_rest_of_message(5); : : }
I concur that given our documentation we are encouraging developers to optimize for known fixed-length messages. Why is now an appropriate time to change that guidance? What has changed between when this guidance was added and now that invalidates that guidance?
We are going to have to assume people have done just this if we ever do make an impacting change in this area. I'd rather keep the documentation consistent so if that change happens in 6 years the documentation still reflects the reality we are dealing with.
I can see adding an explicit warning that these length constants are not promised to never change in the future - but also that we'd have some kind of versioning bump that would go along with it. If the optimization is taken at least test up-front that the version being seen is known to have these fixed values.
