Q:

Detecting complicated CSS selectors

This is a follow-up to What makes a good selenium locator?
Motivation
I've been thinking about detecting the complexity of CSS selectors statically.
The scope I'm working in is both test-automation and web-scraping where choosing a reliable CSS selector is important to be as less dependent on UI/markup/layout changes as possible.
Currently, I'm able to check the "depth" of a CSS selector by parsing it via css-selector-parser and simply counting the number of nodes. If the number of nodes is more than 5 I'm concluding that this is a potentially complex CSS selector. The reasoning behind this is that, the more nodes a selector has in the path, the more dependent on the HTML structure of the page it is - the more fragile it is. For instance, this CSS selector would be considered "fragile" (6 nodes):
.content > table > tbody > tr:nth-child(2) > td.cell > input#email

Eventually, I'm thinking to develop a metric where each selector would get a special "score" value that would a measurement of a selector being more solid/durable. Inspired by famous code complexity metrics, like Cyclomatic Complexity or Maintainability Index.
Question
What parameters would you consider to determine if a CSS selector is resistant to a change? What makes a reliable CSS locator?
Thoughts

usage of layout-oriented bootstrap classes inside CSS selectors would be a signal of a bad locator
implementation-specific classes and attributes would make a selector less reliable. (e.g. in case of AngularJS - ng-scope or ng-binding classes)
using id or name attributes would probably be desirable

A:

What parameters would you consider to determine if a CSS selector is resistant to a change? What makes a reliable CSS locator?  Some factors I would consider:
To start with, the basics are:  

Locator should not include page layout structure
Don't base selector on the actual page text
Work within your existing framework(s)
Prefer css over xpath for readability
Unique and constant css id(s) are best

Then...

Whether nested tables are used or not
Whether data- attribute identifiers are used
Whether a given css id is actually unique or not
Whether literal content text is used in the selector
The use of repeated elements, e.g. div div div
The DOM nesting depth of the first selector element
The number of separate html elements in the selector
How often any existing selector is changed historically
Length of the selector string (number of distinct elements)
Length of the selector string (number of distinct characters)
How many levels of nesting are in the DOM it goes against
Whether partial and wildcard content text is used in the locator
Whether tables are used and if so how rows are ordered / reordered
Use of index identifiers by, e.g. css :nth-child(number)or xpath[]
Use of unique attributes such as id or name with qualifying identifiers
The number of times css ids are used against elements within the selector
How many instances exist of identifiers such as css class within the selector
Whether some id's are all numeric and unique, suggesting database backing
Whether some css element id's are dynamic, e.g. unique resource record id's
The number of times each individual element of a selector appears in the DOM
Whether the selector elements are directly nested or just 'within' other elements
Whether you can see a consistent approach when comparing with other selectors
Whether within 1 table if more than one table td or tr is used in the selector
Use of generic attributes such as span and div without qualifying identifiers on them
Whether the DOM elements are directly next to each others or nested within other elements
Use of a framework like Ruby on Rails that provides unique identifiers for db related elements

The hard part is knowing what weighting to give each of these.  Some will be heavily influenced by the usage of both development and ux frameworks and be more or less relevant in some situations vs. others.  
One way to tell the weighting and predictability of the elements would be to reverse-engineer and review past test breakages due to DOM changes to see the relationships.  In practice I find this hard to do as devs fix tests before committing code.  Larger companies like Google might be able to research this better.
It will be important to also distinguish changing application code vs. automation selectors with this complexity.  A ranking or rating of a given selector may provide good feedback for automators to use in their development of selection strings for automated tests but not be suitable for the page content itself as developed by the ux group.

