Your code doesn't do the complete patience sorting, it does more or less sort, but you're left with some sorted piles of cards after it finishes — typically 11 piles for a deck of 52 cards, I read. You still need to do the second step: pick the lowest card from every pile, but you don't know what pile that is — except when you just start, then it's the leftmost one. It would be some form of merge sort.
No additional sorting is required to find the longest increasing subsequence. As far as picking the lowest card from every pile - that is easy, it is the top card in each pile.
I think you tripped over your wording. I believe you intended to say that at the end of the game, the cards are still not in complete order. While you can get the 1st card for free (the top card on the left most pile), the second card still requires scanning the lowest top card from each pile.
As I said, this is unnessary for finding the longest increasing subsequence which is what this meditation was about. The straight forward approach to finish the sorting would indeed be a merge sort. To make it even more efficient, the piles could be part of a balanced btree. You always select from the left-most pile and then re-insert that pile back into tree based off the card underneath.
The questions to ponder were from the perspective of still finding the longest increasing subsequence.
As far as the binary search. I have 2 versions here to get to the partial sort (sufficient to find the longest increasing subsequence) so benchmarking should be trivial. As far as to complete the sorting - I mentioned one possible way of making it more efficient then a merge sort above but I am not planning on taking it that far. IOW - left as an exercise for the reader. Here is the merge sort though so you have a complete answer to your original question in the CB:
You can avoid push and splice by presizing @order and testing for definedeness respectively. These optimizations along with the use of the binary search are of course up to you.
Cheers - L~R