I assume "The edge-case of duplicate selectors" looks like below:

a:hover {} a, b, a {}
/*         ↑     ↑
 */

In the case above, I think this rule reports the first a and the second a has different column positions.

Gotcha. I think my change doesn't change the behaviour of the rule in that regard, so it should be good to review!

I understand the behavior doesn't change. 👍🏼

I'm concerned about the following edge-case:

{
	code: 'a:hover {} a, b, a {}',
	warnings: [
		{
			message: messages.rejected('a', 'a:hover'),
			line: 1,
			column: 12,
			endLine: 1,
			endColumn: 13,
		},
		{
			message: messages.rejected('a', 'a:hover'),
			line: 1,
			column: 18,    // but actual: 12
			endLine: 1,
			endColumn: 19, // but actual: 13
		},
	],
},

To address this case, we may need to iterate a selector node of postcss-selector-parser instead of ruleNode.selectors:

because we need an exact position of each selector to report a more accurate column position.

The implementation would be a bit too complex for the edge case.

Thanks for the quick review @ybiquitous, and I think I understand now.

To combine what you've mentioned both here and in #6072 - should I write an issue and look to change our implementation(s) to use postcss-selector-parser in the long-term (even if it's not immediate)? Or should we keep it with what we have now.

@mattxwang Thanks for the suggestion. I think both PRs are ready to merge, but it would be helpful if you could open an issue. 👍🏼

... it would be helpful if you could open an issue. 👍🏼

Thanks for the suggestion - have opened #6075, let me know what you think!

Thank you!

Changelog entry added:

Fixed: no-descending-specificity end positions (#6049).