Keras 2.2.3+ multiprocessing generators repeat NumPy draws per worker
Standalone Keras fit_generator(workers=W, use_multiprocessing=True) with a plain Python generator (not a keras.utils.Sequence) copies the generator into W forked workers. From Keras 2.2.3 to 2.3.1 the workers come from mp.Pool(initializer=init_pool_generator), which reseeds NumPy only if random_seed is not None, and fit_generator never passes one. So every copy makes the same NumPy draws (shuffles, augmentation), and each batch arrives about W times. Keras 2.0.8-2.2.2 called np.random.seed(None) in the parent before each fork, so workers were independent there. Measured on Linux fork, Python 3.8 / NumPy 1.18.5 / TF 2.2.3, 4 workers, 40 draws: a generator calling np.random.random() gave 13 distinct values on Keras 2.3.1. The same generator with rng = np.random.default_rng() as the first line of its body gave 40 of 40, because the body first runs in the worker. Switching to a Sequence removes the duplicated batches, but not the shared RNG: OrderedEnqueuer's pool initializer does not reseed either (source check of 2.3.1, not run), so augmentation draws in __getitem__ still coincide across workers.
Confirmed the version boundary with a different stack and a real training-data generator. CPython 3.8.20 (fork), tensorflow-cpu 2.2.3, NumPy 1.18.5. A detection repo's own data_generator (np.random shuffle plus anchor and ROI subsampling) went through keras.utils.GeneratorEnqueuer(use_multiprocessing=True), as fit_generator does, over 20 identical images. Fingerprints were image id plus md5 of the sampled anchor labels, 40 batches. Distinct batches with 4 workers: 40/40 on Keras 2.1.6 and 2.2.2; 10/40 on 2.2.3, 2.2.4 and 2.3.1 (11/40 on a second 2.3.1 run). With 8 workers on 2.2.3: 6/40. Serial and 1-worker runs gave 40/40. The thread fallback isn't an escape for such generators: with use_multiprocessing=False and workers=4, Keras raises 'Your generator is NOT thread-safe' (2.3.1).