first and second points: see my fork.
third: yep, I messed up my reasonning (was thinking about apples, I guess). Note that this remove thing is still O(n), even if you shrink the apples list on the way. Tho, using remove, you iterate a second time on the beginning of apples, while you already did that with the generator. So still a bad idea (Surely that's what I was thinking about, 2 years ago...).

And note too that pop(0) is the worst thing you could do about performances.

see the fork to come.

• elif...:continue Reverse which conditions? Each branch handles a different case, the middle elif block handles the double rotten case. Replacing continue with pass would be equivalent, but the block is required and I'm not sure where you're suggesting I move it to.
• I wasn't aware of the second parameter next(iterator[, default]), good to know
• The only interaction with packed in the else clause is appending. The apples variable is iterated through, but only forward from the current position until a complementary box is found which avoids looking backward in the packed list or looking through the whole remaining apples list.

Expected O(n) time solution without using the built-in sort function.

Not enforced.

Traceback (most recent call last):
  File "/runner/frameworks/python/cw-2.py", line 111, in wrapper
    func()
  File "main.py", line 123, in test_everything
    test.assert_equals(_ref(nums[:]), partially_sorted(nums[:]))
  File "main.py", line 89, in _ref
    counts = Counter((nums[n] & 0xF for n in range(i, j)))
NameError: name 'Counter' is not defined

• don't mutate the input.
• elif...: continue isn't useful, reverse the conditions to skip that part
• use a default value in the generator instead of the try/expect blocks
• you run through your whole packed list each time you reach the else statement, that's not a good idea