Fundamental to any 'broker model' is a message abstraction and a standard way for producers and consumers/subscribers to interact with the broker. After all, the purpose of brokering in many cases is to decouple the producers and consumers so the producer shouldn't have to care what the broker does with the messages it sends. (It may of course want to verify that certain capabilities are supported on the node to which it is sending, and a means of doing this both for producers and consumers is important).

On top of this foundation you can then describe the behaviour of different node types (nodes are simply the sources/sinks for messages, i.e. the rendezvous points). For example you want to specify how a broker will allocate messages published to a node that has multiple subscribers - whether the subscribers compete for the message (as in typical queue behaviour) or whether they each get a copy (fanout or pub-sub behaviour). You will want to specify a set of states and transitions for messages through which storage models can be described (e.g. classic store and forward, reliable pub-sub). AMQP 1.0 does all this. In addition you would likely want selective subscriptions, where subscribers to the same node can specify interest in a subset of the messages published to that node (e.g. the wildcard matching in a pre 1.0 'topic exchange' as compared to the 'fanout exchange' or JMS style selectors). And of course there are other aspect of behaviour (nodes that retain the last value for a certain key, nodes that honour message priority when choosing which message to deliver etc).

Now, in my view, not every 'broker' is going to need/want to support all the same behaviours (e.g. with the pre 1.0 AMQP model support for transaction, durability or priorities was optional, as was support for the topic exchange type. Moreover some implementations decided not to support acknowledgements but to specialise in uses cases that didn't require them etc). I don't think the job of the standard is to force them to do so, but rather to provide standardised approaches for and expanding set of behaviours (perhaps aggregated into profiles for easing comparisons).

The 1.0 specification does provide a way to register extensions. This allows a catalogue of existing behaviours to be built up that then provides a good basis for further standardisation efforts, hopefully driven by real needs and working solutions. I suspect the first thrust here will be on the filters required for the JMS mapping. I can also see initiatives launched to standardise some of the existing extensions from ActiveMQ, SwiftMQ, Qpid etc (message groups, last value 'queues', sticky consumers, probably informally through the respective communities to begin with.

Also relevant here - a different dimension of 'broker' behaviour - is global addressing and standards for creating networks for co-operating components.

I'd certainly be very keen to hear your thoughts on what might be needed for a more 'modern' broker model!

(PS: Sorry this is rather a long post! as someone famous once said, I didn't have time to write a shorter one!).

Well, yes, there's the 'distribution mode' bit, but calling that a broker model is a bit exaggerated. Same way, ZeroMQ does a simple message delimitation on top of TCP, but I am not calling it a 'connection layer' just because of that.

And yup, early versions of AMQP had many deficiencies. However, it's not clear how AMQP/1-0, by stressing the connection layer and ignoring the broker model does a better job.

I would say that people working on messaging should focus on defining a generic, consistent and scalable broker model, but for some reason nobody is doing that. We are still stuck with JMS model. JMS is 11 years old now and the concepts it standardises are ~20 years old. No progress seems to happen. (Just recall how the Internet changed during that time!)

If you have any idea of how to move the broker model forward into XXI. century, I would love to discuss it with you. I have some ideas myself. I'll try to express them in a paper at some point.

The specification defines a 'distribution node' as 'a node that stores
messages for distribution', along with the logical message states
through which messages pass as they are distributed and two
'distribution modes' corresponding to competing and non-competing
consumer patterns.

There is therefore a standardised aproach to the basic pub-sub and
shared queue functionality ('Topics' and 'Queues' in JMS parlance).

(2) "I would say that Exchange-Binding-Queue model is rather a leakage
of internal broker architecture"

It is indeed! That is precisely the reason 1.0 moved away from that
model, to avoid tying the protocol to a particular internal
architecture.

Allowing existing messaging products to support the protocol without
having to undertake a complete rewrite seems to me perfectly
reasonable given the original goal as you describe it.

We are already seeing the fruits of that with new implementations of
AMQP offered or in the pipeline. Greater adoption provides users with
greater choice which is exactly what AMQP is supposed to achieve.

(3) "JMS […] defines a reasonable set of functionality […] the
real challenge of AMQP was to define a wire protocol that could
work as a communication medium between JMS clients and
servers. And early versions of AMQP did just that. The protocol
was basically reverse-engineered from JMS. You could browse
through the specification and map AMQP concepts to JMS concepts in
straightforward 1:1 manner."

This is a misleading picture. Early versions of AMQP were poor in
their support for JMS. The 'basic' class was a very naive translation
of the JMS API into an RPC-ish 'protocol' without sufficient
consideration of the functionality JMS offers. As more fully
functional JMS implementations were developed, the limitations became
clear.

I would argue the central 'concept' in JMS is that of the
'Destination', a symmetric redezvous point to which messages can be
sent and from which they can be received. The mapping of this to the
'distribution node' model is much more straightforward than it was to
the 'Exchange-Binding-Queue' model.

By the way, the described scenario is nothing unheard of in standards development. In fact, it exists, to some extent, in any standardisation effort. See, for example, here: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ The only aspect where AMQP stands out is the scope of the phenomenon (dropping the whole semi-established standard).

I'd be curious to hear an alternative explanation though.

I don't know whether Microsoft was the reason to abandon the 0.9.1 model but you may be right here. Market power is what is important and if Microsoft initiated the move then I can only pass a big thanks to them. I don't think, however, that AMQP 1.0 will be changed that much in future. It is an OASIS Standard and it took about a year for the transition from the AMQP Working Group release with only editorial changes in the spec (no functional or protocol changes). Next step is the ISO Standard so every new release has to go through these stages. But even a change to make a protocol better is no problem for a versioned protocol.

Beside personal-psychological or business reasons to save an existing user base I really don't get why there is such a hate against AMQP 1.0. Don't spend your time with such a negative stuff. Instead be part of the move and just add AMQP 1.0 support to ZeroMQ and your fork. ;-)

You mention two recent articles on AMQP, I presume one of them is this one by @kellabyte, what's the other one?