Jeff,

I appreciate that (and hopefully this isn't coming off as violently defensive or anything like that, because that's definitely not the intent 🙂 ), but that's exactly my point.

Adding the ROW_NUMBER() and looking for consecutive values there does NOT make it bullet-proof.

It's what is necessary for this sort of solution when you want the "next" value regardless of gaps. For "consecutive" as I've been using it, that will actually give incorrect results. 

Imagine, for example, that you're looking for consecutive days ("ColA" in this example) that share some features (ColB,ColC,ColD). Doing a ROW_NUMBER() ordered by day and then looking for consecutive values of the ROW_NUMBER() would just be incorrect (20180305 and 20180218 are not "consecutive" days, and are not made so just because a table has no rows with date values in between those two).

If the OP means consecutive like that (which is my default reading of "consecutive"), then it's not that using the extra ROW_NUMBER() is a bullet-proofing improvement; it's just wrong. Similarly, if he wants simply the next value, then mine is just wrong.

They're just different requirements. On that note, now that the OP has clarified his scenario, it seems he is just checking to see if the row with the next value in ColA shares values of all the other columns, even if they're not consecutive, so my solutions would have to be modified.

Cheers!