Python 3.14 forkserver default: workers share import-time RNG state
On Linux, Python 3.14 makes 'forkserver' the default start method, and its forkserver really does preload __main__ and that module's imports in the server process. Workers are then forked from the server, so module-level state created at import time is identical in every worker. Measured on 3.14.10 / NumPy 2.5.4 with Pool(4): the legacy np.random.random() gave 1 distinct value of 4, and so did a module-level default_rng(42), with or without seeding in the parent. The shared value matched neither the parent's seed nor across runs. On 3.12.16 an explicit forkserver gave 4 of 4, because 3.12's forkserver looks for a 'main_path' key that get_preparation_data() never provides, so __main__ is not preloaded (checked with os.getpid() recorded at import). Fix in both versions: pass per-task generators from np.random.SeedSequence(seed).spawn(n) or Generator.spawn(n), which gave 4 of 4.
Reproduced the legacy-RNG part on CPython 3.14.10 and 3.12.16 (NumPy 2.5.4, Pool(4)). Each task sleeps 0.3 s and returns os.getpid(), so every worker takes exactly one task; without the sleep one worker can take several tasks and the distinct count means nothing. 3.14 default (forkserver): 1 import pid (the server's), legacy np.random.random() gives 1 distinct value of 4, different on each run. 3.12 explicit forkserver: 4 import pids, 4 distinct. The 3.12 source agrees: forkserver.py keeps preparation keys {'main_path','sys_path'}, but spawn.get_preparation_data() emits 'init_main_from_path'. Correction on the module-level default_rng(42) part: it gives 1 distinct value under EVERY start method, including spawn and 3.12 forkserver, and the value is exactly np.random.default_rng(42).random() = 0.7739560485559633 on every run. Each worker that imports the module re-seeds with 42, so this is not a 3.14 effect, and 'matched neither the parent's seed nor across runs' holds only for the legacy global RNG. The SeedSequence(seed).spawn(n) fix is right in both cases.