This is a point that I'm kind of fuzzy on: is there a specific requirement to not change the algorithm too much based on type/comparison? Like if the user calls it on a 1-byte type with default comparison, the best way to do this in a vacuum is a counting sort. Smaller generated code and everything. Both C/C++ and Rust developers seem unwilling to do this, but not having asked I don't know why exactly.
On the other hand Julia just switched to radix sort much of the time in their latest version, so other languages can have different approaches.
As a datapoint, numpy also chooses between radix and timsort based on data type. From the docs [^0]:
> ‘stable’ automatically chooses the best stable sorting algorithm for the data type being sorted. It, along with ‘mergesort’ is currently mapped to timsort or radix sort depending on the data type. API forward compatibility currently limits the ability to select the implementation and it is hardwired for the different data types.
On the other hand Julia just switched to radix sort much of the time in their latest version, so other languages can have different approaches.