This is for type resolution related bugs, calling it tracking issue, since I think we may stumble over a few more. As of now, none of these seem high profile at all.

1. In ResultType the ret_is_small_unsigned flag is never cleared. This means that in an operation mixing arrays and dtypes, the dtypes can be handled incorrectly with respect to the arrays:
   np.result_type(np.uint16, np.int16, np.uint8(127)) should give int32 but gives int16, because of the 127.

2. Less important maybe: The order of types can matter, thus, replacing an array with arr.dtype in result_type can cause a different result (since specific dtypes are handled last). This is mitigated mostly now with some weird logic (see common_dtype.c), and would only happen for weird user-dtypes.

3. np.ufunc.reduce(..., out=...) does not check output dtype at all when given.

4. can_cast(np.float64, "S") is always True, but can_cast(np.float64, "S100") is False even though it is long enough (missing check to see if the string is long enough). (Just to be clear it should never be safe casting to begin with, because it loses the information that it is a number) The main issue is gone (the safety/promotion has its own issues open).

5. Flexible is defined by size == 0 right now. This means that "S0" does not really exist, another example is this one:

   In [5]: dt = np.dtype([])
   
   In [6]: arr = np.arange(100)
   
   In [7]: arr.astype(dt).dtype
   Out[7]: dtype({'names':[], 'formats':[], 'offsets':[], 'itemsize':8})
   
   In [8]: dt.itemsize
   Out[8]: 0

6. Object arrays being coerced with np.array to a string dtype are always coerced to length 8, while the same as a nested list would be coerced by checking the elements length. This might be OK as such, but also differs from what happens during casting, using nested_arr.astype("S") will discover the length correctly. This one was fixed in NumPy 1.19 (I believe).

7. (More of a note) It is possible to subclass numpy scalars classes. When numpy sees those during coercion, it checks scalar.dtype (effectively). This means that subclasses get coerced to the superclass dtype. In practice, numpy scalars should probably not be subclasses, so that it is not a realy issue (even if we would change it). NOTE: There is dead code that would deprecate this, although it might need some more thought.

8. The UFunc sig/signature argument is broken when the input is neither a tuple nor a string: np.add(1, 2, signature=np.dtype("int64")) – small thing, but should likely get a test when/if fixed. Gives a useful error now (probably since 1.21)

9. The UFunc dtype=... kwarg forces the first input dtype (of the loop) to that dtype. It would make more sense to force the output dtypes instead. This could probably be simply changed. The only likely breakage would be for ufuncs with multiple outputs with different dtypes. This is changed now.