The reason we use separate Order IDs from Order Numbers is primarily to accommodate sites that use alphanumeric or non-sequential identifiers for orders. Because every other serial numeric entity identifier is called an ID, we use the Order ID as that serial numeric value. We then use the Order Number as the customer facing identifier for an order as a character string in the database, supporting both numeric and alphanumeric identifiers.
One drawback, as you've noticed, is that this results in ill-fated Views sorting. This is a known issue that I meant to fix prior to releasing Commerce 1.4 but forgot. We'll address it in the Commerce 1.5 release through this issue.
In the meantime, you can simply edit the Orders View, add a hidden Order ID column, and sort on that. Or, you can just replace the Order Number column with the Order ID column and stick with that if you're building a site where you know for certain that will be sufficient, which is probably most cases.
I don't think we'll change the architecture of this, but moving forward in this and other areas of Commerce, we do want to ensure that engineering for the edge case doesn't overrule the majority behavior expectation / requirement.
Comments
OK, that makes sense about order number, thanks.
I was confused about order_id not being sequential.
In actuality, my user had many old "status=cart" records in `commerce_order`, so that it appeared as if order_ids were being re-used, when actually commerce was merely re-animating a zombie order record.