Well as for me: Just curiosity. I used QueueAsynCall before, and never came across such need.
But then that is because in a case like this, I would queue only one call, and have a list for that call, to which I can add at any time. Once the call was done, I queue the next.
Of course that would simply be my approach. That does not say it is better or worse, than having many async calls.
Actually it may have one advantage. If you queue 1000 async calls, afaik they will run all in one single block. There is no other processing in between. Your app, may become none reactive for a moment.
If I have just one call, then I can specify to process only the first x (e.g. 50) items, or process until 100 milliseconds have passed, and schedule a new async call for the next round (after events were processed again)
If your code is not time critical, or not going to reach such extends, then it does not matter.
-----------------------
As for the feature request, the code in question is not maintained by me, so I am not going to make the decision on it.
But in cases like his, the question (IMHO) always is, if the problem that is being solved is generic enough to justify the added maintenance.
That is, I do NOT say, that your code burdens a lot of maintenance on the current implementation of AsyncCalls. But if, or if not is something I will not be deciding.