@PeterJeffreyGale, you bring up a good topic.
I try to follow that too. In terms of text related elements, that often or sometimes gets associated to matching by element/node text that a user sees on the screen. And when paired with parent/child/sibling/etc. XPath relationships can be used to match/reference other elements relative to the text (e.g. you have a group of elements that define a feature - the checkbox or radio button, the text label we key off of as the relative root, the click handler (if not the checkbox/radio button itself, etc.)
Unfortunately, taking this approach deviates from going with CSS selectors, which are often (or used to be) faster than XPath, because CSS doesn't offer element/node text matching. So I end up using XPath often just because I want to take that approach, where I know the visual text change is easier to track & verify than changes in the underlying attributes (class, ID, etc. particularly for elements sem-auto-generated by popular javascript libraries).
Is what I describe what you aim for as well?