Thanks for the POC. I'm still hesitant. maybe we doa refactor but keep the new command in contrib. Logging will be an issue. Its not clear which queue some log messages and errors are referring to.

I did some work on improving the logging:

• every new queue where an item is claimed is announced (giving context to any errors that may follow)
• every queue where an item has been claimed gets a summary at the end, the same one as queue:run
• at the very end of the command execution, a global summary is shown (amount of items and time elapsed)

To be clear, 'Processed X items' does not include failed/skipped items.

I added the --daemon option as well, will work on the --memory-limit option now. If not for Drush core, for contrib.

I added the --memory-limit option as well. The MR is all ready now, I just started using the new command in a Supervisor config on a production site as test and it seems to be working so far.

If we decided not to merge this into Drush core, I will probably start a new module with the queue:run-all command. I don't think I'll be able to add the changes to the queue:run command (the new --daemon and --memory-limit) in contrib though.

That said, I am still fan of the idea of adding this to Drush core. It doesn't add a lot of code or complexity and it's very useful.

1. I dont especially want to do more memory checking in Drush. We've done that in the migrate commands and it confuses people. See drush deploy disregards php's memory_limit parameter #4899 (comment)
2. Why do you think the item-limit should span across queues? That seems weird to me.

Keep the command running indefinitely, or until one of the chosen limits has been reached

If the memory limit is reached, won't folks expect the command to restart itself? Should the above statement only apply to items and time limits?