foreach($papers as $paper)
$sorted_papers[$myclass[$paper->name]] = $paper;

It all simply boils down to that ya?
that’s Linear paper arranging in my book….

You don’t need to have “fixed” width buckets to have constant time look up. But I concede that in general you are correct when you say that completely arbitrary bucket widths is rarely a constant time look up (barring the creation of some prohibitively large look up table).

As for your second comment, I’d encourage you try to a bucket sort versus a quick sort on 30 papers (or a deck of cards). You’ll find the bucket sort is substantially better

To your more important point, though, that as the data set get larger, a “naive” bucket sort becomes problematic. This is true. If you mildly alter the bucket sort into the iterative variety, like a postal sort or radix sort, it will still outperform quicksort for large N.

In your original example the teacher was sorting names. When you argue O(1) bucket lookup you use integers and you specifically switch to evenly distributed integers because that normalizes both the range of values for the bucket (bucket width) and the number of entries in the bucket (bucket depth). That doesn’t match with the task you are comparing to.

You can either have uneven “bucket width” to keep the bucket size under control at the cost of log(n) bucket lookup (not to mention n*log(n) to gather the data to size the buckets), or you can have fixed “bucket width” (constant lookup time) at the cost of paying an n^2 sort for clustered buckets of n elements. The problem is that the penalty for clustered buckets grows very quickly (average of the square of the element count) and it must stay under log(n) which is a very slow growing function.

You’re trying to show that bucket sort, with insertion sorted buckets, will beat the n*log2(n) performance of quicksort quite handily for sets like names. I don’t think it is going to work. In a class of 30 students, it’s about a wash. Things get much worse the larger the set is.