Taking a look at Deno KV Queues there are a few things that appear to be missing to me to make it an effective solution:
Ability to "peek" into the queue without consuming any messages.
Ability to get some information about the queue, like the length. Especially with deploy having a max queue size, there is potentially a user land need to deal queue sizes preemptively instead of dealing with a hard fail on the message.
Ability to support multiple queues/topics. Any sort of complex application could easily need to segment queues by type and messages, allowing a specialised listener.
Nice to haves:
Setting the "dead letter" key per message enqueued is not super ergonomic.
If having multiple queues/topics is created where there is a "queue" instance, it could unlock a few other usability options like strongly typing the message via TypeScript or other queuing mechanisms (FIFO is obviously the most common, but there are use cases for FILO queues as well) and ability to manage/change retry behaviours.
Taking a look at Deno KV Queues there are a few things that appear to be missing to me to make it an effective solution:
Nice to haves: