Backwards incompatible ideas for a major release

This is a collection of ideas for changes that would break backwards compatibility and be inappropriate for anything but a major release. If/when we do make a major release, we can then go through this list and see what can be taken along.

Python APIs

• Make the default integer type int64 at least on python 3, no matter what long is on the system (from @seberg).
• overhaul casting rules to avoid things like uint64 + int64 -> float64. Perhaps use "C-like" casting instead. See https://github.com/numpy/numpy/issues/12525.
• Casting rules for arithmetic are value-dependent for scalars (https://github.com/numpy/numpy/issues/6240)
• result_type(int, str) should be object, not str.
• Require explicitly writing dtype=object to get an object dtype array.
• Find a solution to issues created by PyArray_Return: That is, most numpy functions, importantly ufuncs, convert 0-D array results to scalars when returning. This could be a breaking change returning arrays always, or more complex solutions. Possible steps forward that do not require breakage (immediately) are discussed in https://github.com/numpy/numpy/issues/13105.

C APIs

• Removing NPY_CHAR (see https://github.com/numpy/numpy/issues/2801 and linked PRs/issues)
• Dtype cleanup ideas (see https://github.com/numpy/numpy/issues/2899)
• Make the PyArray_Descr and PyUfunc_Object structs opaque like we did with PyArray_Object, extracting PyArray_Descr_Fields etc - this allows us to make API changes more easily later.
• modify NPY_SORTKIND to allow different sorting algorithms (timsort, radixsort). THis requires a change in size of PyArray_ArrFuncs See https://github.com/numpy/numpy/pull/12586 https://github.com/numpy/numpy/pull/12586
• Increase NPY_MAXARGS to more than 32, see https://github.com/numpy/numpy/issues/4398.
• implement radixsort once sort ABI can be changed, see https://github.com/numpy/numpy/pull/12586