I would also like to see a queue system with better guarantees. We've been running RabbitMQ for a couple of years and are fed up with its lack of safety in the face of minor cluster failures.
I don't know about NSQ — it looks nice, but the lack of true persistence and ordering means it's not something I can use. For example, lack of ordering means you can't use it as an event bus for document-oriented changes.
I know it's not a popular sentiment these days, but I prefer to err on the side of correctness. I have had enough of systems that are supposedly SPOF-free but still fail for mysterious reasons and are nigh-impossible to debug once they do (ElasticSearch, ugh).
RabbitMQ's lack of transparency means it's harder to work with the contents of a queue. For example, if the queue processing has stalled for some mysterious reason, what's clogging it? With RabbitMQ, the only way to peek into a queue is to actually pop messages from it (using a tool such as rabbitmqadmin or amqp-dequeue).
Another problem with RabbitMQ is that messages go away after being acknowledged. I, for one, would like to see a bit of history. Sure, you can build this into individual apps, but it turns out this kind of history is beneficial for many kinds of apps. There's DLX, but you can't (afaik) set up rules to automatically copy acked messages into a history queue.
I can't say I like AMQP. Binary protocol, requires several layers of client tooling to work with. If anything goes weird, strace or tcpdump are of no use. It's also a very complex protocol whose interpretation and matrix of support features seems to change a lot.
I'm currently writing a small job manager in Go that's backed by PostgreSQL (at least initially) because I want something safer, more stable and more transparent. It's based on my realization that jobs are different from events, and should be treated differently.
For example, RabbitMQ has no conception of scheduling or prioritization, and messages are ephemeral objects that go away once they've been acknowledged, as opposed to jobs, which have a life before, during and after processing.
So far, it looks pretty good. Postgres can't process a bazillion messages per second, and it's not going to work for "big data", but it seems to scale decently enough.