I can see the use case, but I feel that many brokers will want to simply kill the TCP connection dead...

If we make this MAY, then we give information to an attacker who can exploit the differences in behaviour to sniff a broker type...

Discussed on TC Meeting (23.05.2013): requires more discussion to progress.

Here is a summary of this issue to try and move the discussion forward.

1) CONNECT in MQTT is unique in that the CONNACK response can convey a negative outcome.
2) Other commands PUBLISH SUBSCRIBE UNSUBSRCIBE etc. do not allow for the possibility of a negative outcome so the only action
the server can take is to disconnect the client if it cannot process the command.
3) In the case of CONNECT processing, there is a conflict between wanting to provide some feedback to the client as to why its connect request could
not be processed, versus not giving the client information which might help it perform a denial of service attack.

Related / dependent issues are:
MQTT-15 Should the CONNECT packet Protocol Name and Protocol Version fields be changed?
MQTT-6 What should a server do if it receives a connect packet with and incorrect protocol name?
MQTT-22 Specification is ambiguous with regards to dynamic topics.
MQTT-38 Malformed QoS for topics in SUBSCRIBE packet.

Straw man proposal.
If an MQTT Packet cannot be processed by the server or client then the server or client MUST immediately disconnect the TCP session.
The client or server might want to log some diagnostics locally as to why the TCP connection was disconnected.

The server should attempt to flow the following connack return code before disconnecting the TCP session if the CONNECT packet can be processed but the Protocol name and version are not as specified by issue MQTT-15.
1 0x01 Connection Refused: unacceptable protocol version - The server does not support the level of the MQTT protocol requested by the client.

The following CONNACK return codes are never used.
2 0x02 Connection Refused: identifier rejected
3 0x03 Connection Refused: server unavailable
4 0x04 Connection Refused: bad user name or password
5 0x05 Connection Refused: not authorized

Reworked proposal to return focus to original Connect Packet issue.

Take to TC call 19.09.2013

Added in WD-12

If a correctly formed CONNECT packet is received by the server, but the server is unable to process it (for some reason), then the server SHOULD attempt to flow one of the following CONNACK return codes before disconnecting the TCP Connection. The values for the one byte unsigned CONNECT Return code field are shown in the table below.

If none of these return codes are deemed applicable, then the server MUST disconnect the TCP Connection without flowing a CONNACK.

table with return code is fixed