NumPy 1.x used value-based casting: the dtype of np.uint8(200) + 100 depended on whether the literal fit in the array's dtype, and could quietly promote the result to a larger type. NumPy 2.0 implements NEP 50, where a Python int, float or complex is a weak scalar that adopts the dtype of the array operand.
So the result of that expression is now uint8, and because 300 does not fit it wraps to 44 with RuntimeWarning: overflow encountered in scalar add. Under NumPy 1.x the same line produced int16 and the value 300. Nothing raises, so the difference shows up as wrong numbers rather than a traceback.
Audit any code using small integer dtypes, uint8 and int16 in particular, which is common in image processing and in memory-tuned pipelines. The fix is to be explicit: cast the array with arr.astype(np.int32) before the operation, or use a typed scalar such as np.int32(100) so the promotion rules see two typed operands. np.result_type(arr, 100) tells you what a given expression will produce before you rely on it.