I don't think it needs to be required, but I'd 100% include that in any linter or style guide I had for code.

For production code, I'd use it 100% of the time. For just quickly reorganizing some syntax around and copy/pasting things, I appreciate the shorthand version. I wouldn't use it in a codepen in most situations.

I very strongly agree. Mandatory & makes things much clearer, for a negligible cost. (And really, the curly braces, colon and semicolon are all mandatory (well, except the last semicolon of a ruleset), and alternative syntaxes with less punctuation like Sass’s have failed; the & is frankly more consistent than its absence.)

For a more technical justification: with optional &, priority is given (by brevity) to the descendant combinator, but what of other combinators? Do they require & or not? It could reasonably go either way. I haven’t read recent proposals, but am very familiar with CSS grammar, and I’m genuinely unsure.

  parent {
      /* This might or might not work. */
      > child {
          …
      }
  }

  parent {
      & > child {
          …
      }
  }

This is another good point, particularly because (IMHO) people tend to overuse the descendant combinator in places where they should really use the child combinator instead.

Optional and being able to require it with e.g. a linter on a per-project basis seems better idea for me, since I'd strongly prefer not using & and for the vast majority of cases (as we learned from SASS) it's not needed.

Q for Smarter people than me with more experience: is it better to require stricter upstream and loosen the downstream (so would require &, and MyCSS framework could insert them where needed) or looser upstream and tighten local code with linters?

"be conservative in what you do, be liberal in what you accept from others" applies?

The problem is that "MyCSS framework" would not be a CSS framework, it'd be a full build system if it's incompatible, so that way no one would use the looser form. So if it's looser upstream, you can always tighten it more downstream in a fairly seamless and optional way, while the opposite is not really true.

I don't know, I have been using SASS/LESS for a while and I almost never use the & because 95% of the time, I am talking about a descendant when I use nesting. I think it would be very easy to accidentally typo or miss in a review the difference between "& .sub-class" and "&.sub-class."

Unfortunately, you would still have the problem of seemingly-arbitrarily needing `:is` in some cases, when the & isn't at the start of a declaration.

So e.g.

  .someClass {
    :is(a) > & {
      font-weight: 700;
    }
  }

instead of the more intuitive (but impossible)

  .someClass {
    a > & {
      font-weight: 700;
    }
  }

They need to just bite the bullet and devise something other than & to clearly distinguish nesting.

It's not the & that's the problem, it's the selectors that start with a regular letter or dash (i.e. `a` in my example above).

The point is that if & cannot consistently serve as a marker, then it shouldn't be one. Just add a different piece of syntax that always starts a nested rule and clearly disambiguates it and retain & solely to designate the parent.

Ah, so you're calling on people to vote for option 4 or 5?

I agree completely, and having followed this since it was a pipe dream, I’m actually sad that the machine parsing and unambiguous human readability convergence lasted so long to hold this up only to fall apart as it becomes a real possibility.

strongly agree as well. Option 3 with required "&"