Still not what I would call 'proper' queuing (IMHO!) because ultimately it's still just Kafka and just append only: you can't 'atomically acknowledge+delete' individual messages anywhere in the stream, you only dealing with offsets and that's a fundamental thing that has many consequences (e.g. you don't get ordering between batches) and also means that you will get re-deliveries in some scenarios that you would not have with a system that implements proper queuing.
Let's not forget NATS.io which does queuing (and a whole lot of other things from at least once low latency pub/sub to request/reply, streaming and all the way to KV and Object store) very well and is very light weight to run and much simpler to run than Kafka.
From the exit proposal: "Over 97% of contributions to the NATS.io server were made by employees of Synadia and its predecessor company".
Also, when they applied for graduation in 2018, they were told no because most of the contributors work for Synadia (https://github.com/cncf/toc/pull/168). As of now 7 years later, it's still not graduated by CNCF. At this point it likely never will.
Putting yourself in their shoes, are your surprised they want to take it back from CNCF?
NATS does much more than pub/sub (with any fan out), it also does queueing in Core NATS (no persistence) and streaming including queuing over streams (with ack/nack/term). Don't be fooled into thinking NATS doesn't do queueing because it doesn't have a "Q" in the name :).
Yes, one of the many differences (advantages) of NATS JetStream over Kafka: with NATS you can ack explicitly each message individually, and even better if you set your stream to be in 'work-queue' mode it will also automatically (and atomically) delete the ack'd message from the stream (i.e. like a 'proper' queue) another difference with Kafka where you can't delete individual messages in the middle of a stream (only trim the tail end).
You can also 'negative ack' messages, specify a back-off period before the message is re-delivered (because NATS automatically re-delivers un-acked (or nacked) messages) when you can't temporarily process it, or 'term' a message (don't try to re-deliver it, e.g. because the payload is bad), or even 'ask for more time before needing to ack the message (if you are temporarily too slow at processing the message).
NATS JetStream also implements subject-based addressing at the stream level (unlike Kafka where 1 stream = 1 topic, and you can only use the message's key for distribution, not for addressing).
So you can for example ask for [the first/the last/all] of the messages on a particular subject, or on a hierarchy of subjects by using wildcards. All the filtering is done at the server level.
The 'auth callout' feature introduced in NATS 2.10 is there exactly for that (integrating NATS auth with whatever existing IdP system you already have): the client app passes whatever you use as it's credentials at connection time the server then passes them to the security callout service (something you write, following a template that receives whatever the client app passed as credentials and then works with whatever system you have to check those credentials and whatnot and then generates on the fly and returns to the servers equivalent NATS credentials which in turns uses them for that client connection.
(https://github.com/nats-io/nats-architecture-and-design/blob...)
IMHO and I would argue that JetStream functionally does much more than Apache Kafka (e.g. stream filtering using subject based addressing, stream with working queue semantics, constraints on streams, compare and set (so you can do CRUD operations), stream sourcing and mirroring, etc...), and has many (most?) of the features of Kafka Streams.
(note that NATS Streaming is a now deprecated predecessor to NATS JetStream)
Pull does have advantages over push (e.g. one-to-one flow control since the transfer of the messages is initiated by the client (pull requests)), and they are basically functionally equivalent (only thing push can do that pull can not is send a copy of all the message to all the subscribers, should you ever need it). They both exists because historically push came first and then pull later).
As a developper using NATS JetStream you should really not have to worry about push or pull, you should just care whether you want to consume the messages via call back or via an iterator or via fetching batches, after that whether pull or push is being used underneath the covers is irrelevant to you.
And this is exactly how it is in the new JetStream API (https://github.com/nats-io/nats.go/tree/main/jetstream#readm...) you don't have to worry about push/pull anymore and you can consume in any of the 3 ways described above (callback, iterator, fetch batch) it's all a lot simpler and easier to use.