Yes, I tried doing the seen sort join thing before the matches thereby avoiding the 2 - 1, 1 - 2 overhead, but with the data given, there was no benefit (in fact it was slower).
I did benchmark your code against mine, and on the DATA, mine was about 40% faster. Possibly on a much more extensive set of data, the difference wouldn't be so great.
Comment on Re^3: nested combinations: algorithm advice?
The given data was only a sample. [Yes, I probably should have said this. In retrospect, there are quite a few things I could have done better with my original question.] The actual data has several thousand lines. Yours may still be faster, but then there would be the additional step of eliminating the duplicate combinations.