In lesson 1 you wrote Item and put limits on two of its fields:

const (
	MinYear   = 1900
	MaxYear   = 2030
	MinRating = 0
	MaxRating = 100
)

And the text said: "So these two fields get their limits now, eight lessons before anything needs them."

This lesson is those eight. It is what those two bounded fields were for — their own payoff, separate from -sorted, which lessons 7 and 8 have already used and is not finished with you yet.

Guess before you read on

In lesson 8, merge sort did about 1.7 million comparisons on 100,000 items. In lesson 7, insertion sort did 2.5 billion.

What is the fewest comparisons a sort can make and still be correct?

Write your number down. It is almost certainly too large.

Why the comparison bound exists

A comparison sort is a decision tree: each comparison yields one bit — yes or no — and you need enough bits to tell apart every possible starting order.

n elements have n! possible orders. To identify one out of n! you need at least log₂(n!) binary decisions, and log₂(n!) ≈ n log₂ n.

That is Ω(n log n): no sort that decides by comparing can do better. Merge sort reaches that bound — it is optimal in its class.

And why this lesson's algorithms do not break it

They do not beat the bound. They step outside it.

The bound is about algorithms that decide by comparing elements with each other. This lesson's algorithms never do that — not once. They do not ask "does A come before B?"; they take the key and simply count how many times each value occurs.

Ω(n log n) applies to comparison sorts. Stop comparing, and the bound stops applying to you.

This is not a trick, and not a hole in the theory. It is a different set of assumptions, and you pay for them — the price is step 5.