Major One of the major problems for large scale shared infrastructure environments is how to debug issues between the client application, client library, and server. MQTT has only minimal error reporting, and even adding more return codes does not give the application developer any detail about what went wrong.
In a simple legacy environment there was commonly a server in a test environment, and a client app in development used this test server and was able to find problems by looking at the server logs. In shared infrastructure environments, it is common to test client applications in a production environment, and it is often difficult for the client application to get information from server error logs about the details of any failure.
This debug information might be of less value when both client app and server are running in production mode. A server would also need to balance the value of this information for debugging against the potential for abuse.
As we have added the concept of optional values (metadata) on control packets, it makes sense to use this facility to allow debug level error reporting on various control packets, mostly the ACKs and DISCONNECT. This would add an optional string value. This string is defined as for human consumption and is not defined by the specification.
A similar facility exists in the WebSockets disconnect where they specifically say that clients should not parse this data but can present it for logging purposes. In JMS where the APIs but not the wire protocol are defined, many providers send back this sort of information and put it into the exception data. In HTTP it is common to put such information into the content when returning error status.
It might also be useful to have an optional value on CONNECT as an indication from client to server that the client is under debug and wants extra problem determination information. The server would need to decide if it will grant this request and how much information it will return.