multiprocessing.Queue.empty() returns False after all producers have exited on Windows 3.13.3

On Windows 11 with CPython 3.13.3 official installer, Queue.empty() incorrectly returns False when the producer process has already terminated, allowing a later-started consumer to successfully get() all buffered items. This contradicts the documented behaviour that empty() is only reliable while producers are alive.
To Reproduce
Save as clean_test.py:
Python

from multiprocessing import Process, Queue

def x(q):
    for i in range(4):
        q.put(i)

def y(q):
    cnt = 0
    while True:
        if q.empty():
            break
        q.get()
        cnt += 1
    print('实际 get 次数：', cnt)

if __name__ == '__main__':
    q = Queue()
    p1 = Process(target=x, args=(q,))
    p2 = Process(target=y, args=(q,))
    p1.start()
    p1.join()          # producer already dead
    p2.start()
    p2.join()

Run:
powershell

python clean_test.py
Expected behaviour
Should print 实际 get 次数： 0 (consumer sees empty queue).
Actual behaviour
Prints 实际 get 次数： 4 (consumer successfully gets all items).
Environment
OS: Windows 11 (build 22631)
Python: 3.13.3 (tags/v3.13.3:6280bb5, Apr 8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)]
Installer: official python.org x64 exe
File SHA-256: 4D8746575FF5D9062D159EB0C382589DBFEC56C942D23DA57E44CF1920312D57
Additional context
The same script always outputs 0 on Linux (CPython 3.11-3.13) and on Windows 10 with 3.11.
Appears to be Windows-specific and version-specific (3.13.3).

Beginne mit dem Reproducer clean_test.py und führe ihn unter Windows 11 mit CPython 3.13.3 aus. Vergleiche anschließend die Ergebnisse von Windows 10 und Linux, die im Issue beschrieben sind. Untersuche multiprocessing.Queue.empty() sowie den Lebenszyklus von Producer und Consumer. Als abgeschlossen gilt die Aufgabe, wenn der Windows-3.13.3-Fall nach dem Beenden des Producers 0 Elemente meldet, ohne die Vergleichsumgebungen zu verschlechtern.