What an extremely well thought-out piece. There is a certain bias towards MQTT’s suitability for building Azure-scale services (the article says as much), but I just wanted comment on a few general points.

> you cannot return connack (which confirms establishing or recovering a session) until all server nodes have access to a replica of this fact. The spec doesn't say that.

The spec should not have to say that. If you're building high-availability, distributed brokers (which MQTT makes no claims about), the semantic implications of each message should certainly be considered carefully, but a protocol specification is not a "how-to" guide enumerating every use-case. A brief note calling into consideration special cases may be welcome, but should not be required.

> With a "pull" based model that separates establishing subscriptions and message solicitation, you can leave delivery resumption control to the client, with MQTT those two aspects are coupled.

This behavior is a non-issue if the clear session flag is set. If it's not being set, the assumption is that subscription state is actively managed by the server. Leaving more work to the client is half-hearted and would complicate the protocol into something like AMQP’s. (I have thoughts about whether pull models are best suited for stateless operation, but that’s neither here nor there.)

Client IDs are indeed mis-named. To be fair, the 3.1.1 spec allows for server-assigned client ids. That doesn't completely mitigate the security risk, as user credentials are allowed to be shared among endpoints. This can be “fixed” at the broker level by requiring unique credentials, depending on the use case — it likely wouldn’t work for Azure.

The objection to the (lack of a) payload encoding is unclear. Being payload-agnostic actually a nice feature, especially on the broker side. Crucially — and please correct me if I'm wrong — MQTT is not designed as a generic mechanism to communicate with unknown clients, vis-a-vis HTTP. Clients are assumed to have awareness of the payload structure. Metadata can be further signified via a structured topic (again, clients know the format of the topic).

The article calls the structured-topic approach a hack, but it is a easy, readable method to impose simple structure or namespacing, and allows for things like metadata-based routing without any special effort from the broker. Hence, the need for explicit metadata (content-type, etc) seems unnecessary.

Regarding flow control — unless the spec declares otherwise, the broker is free to implement specific policies regarding the number of in-flight messages. For example, Mosquitto handles ACLs out-of-band. Otherwise, you can rely on TCP buffers to limit in-flight messages, or delay a QoS response until the next message can be handled. This also applies to data management policies, e.g. state or message retention, QoS-2 allowances, and so forth. Spec ambiguity is not necessarily a bad thing here. Over-specifying could constrain other use-cases; the insistence on “watertight assurances” doesn’t always hold water.

Multiplexing is not really an issue, unless you are sending large payloads — although if you are, I would venture to say you’re not using the right protocol anyway. I will place fault with the protocol for allowing 256MB payloads — this really just goes to show the incongruity between MQTT’s frugality with headers and wastefulness everywhere else.

All this assumes the user is using MQTT as it was designed: for simple pub-sub. What it allows out-of-the-box may not be flexible enough for many use cases. These problems can be mostly fixed with small changes to the protocol, or fixating on certain assumptions. This usually necessitates writing/modifying your own broker, but fortunately MQTT is simple enough that it isn’t a heroic deed. Of course, this doesn’t apply if you’re building a SaaS broker like Azure — but for any other purpose, MQTT can be viewed as a springboard.

Granted, all this sounds like it requires thinking too much about details that should otherwise be solved by things like AMQP. Maybe so. However, more sophisticated systems have many more knobs to tune, and the complexity rises accordingly. MQTT doesn’t have that problem out-of-the-box.