> The documentation indicates that numbers are permitted

That should have been integers. Both in the documentation and in the code.

> I gather internal--length-compare (specifically the nthcdr bit) works for “less than” but not for “greater than”, and thus the reversal approach is actually required, not just a way to reduce the quantity of code generated. Is that correct?

It's actually a limitation of the whole nthcdr approach. You can only ever save list traversal on the last argument with <, but not any with > since you need to know whether it will get bigger than the preceding argument.

> But I think

> (length< some-big-list 5)

> could still limit the work it does by using nthcdr, couldn’t it? Implement it the same as:

> (not (length< 4 some-big-list))

This sort of approach could work and would obviate the previous problem as well. I think it would be best to do it in a compiler macro which acts when passed literal numbers rather than variables holding numbers. That case is more common anyway, and it would prevent extra run-time computation.

> The doc string mention of “more efficient” is ambiguous; more efficient than what? Are you comparing against using “length” and “>”? Or are you comparing different ways the arguments to the function might be arranged?

The second one.

I'm actually considering an entirely different approach toward changing the bytecode interpreter which will be backwards compatible, not require new bytecodes, and improve run-time for these cases. If it's acceptable then it will greatly affect how length= and related can and should be implemented.