> I'm sure that exposing the number of unfinished tasks
> (unfinished_tasks class variable) can be very useful in many situations

Sorry, but I don't share your certainty of the usefulness of this method.  Since the task_done/join API was added many years ago, I've not seen any use cases arise where we needed to quantify the number of unfinished tasks.  Have you seen an actual need in real code or is this PR more of an intuitive guess that the extra method might be useful?

In the examples of task_done/join that I've seen, the number of unfinished tasks is typically in the range: qsize() plus between zero and the number of parallel consumers.  Where the actual value it falls this range doesn't seem very useful.  One the queue is empty, join() just waits to the parallel consumers to complete their one final task that is already under way.

Also, I'm reluctant to expand the API for several reasons.  Keeping it small makes it more intelligible (giving users additional options for things theh rarely need makes it more difficult to make correct decisions in the common cases). Also, it would be nice to avoid a ripple effect into the other APIs such as multiprocessing which are supersets of this API. And lastly, I'm disinclined to have another informational method like empty, full, and qsize which have to be documented as potentially introducing unexpected race conditions in user code (all three methods return information that may be completely out-of-date or wrong by the time the caller sees the result).