I'm saying the "&" should be required _at the start_.

Perhaps controversial, I know. I realize this eliminates use cases like

    em {
      color: green;
      li & {
        color: red;
      }
    }

It's okay not to support these use cases. They're confusing because they break encapsulation; the rule that appears to be nested inside (in this case, color: red) is affected by an element on the outside (in this case, <li>).

Compare:

    li {
      color: blue;
    }
    em {
      color: green;
      li & {
        color: red;
      }
    }

To:

    em {
      color: green;
    }
    li {
      color: blue;
      & em {
        color: red;
      }
    }

The second structure is easier to understand, and in my opinion, the syntax should bias you toward writing it that way.

This functional limitation was eliminated from consideration long ago: it’s very common to want that functionality. There were options considered for still denoting nesting, e.g. start all nested chunks with @nest, but this was decided to be inconveniently verbose. I think & is safe from being inconveniently verbose, but you can’t sanely use that without the functional limitation.

On your example: nesting is not about the sort of encapsulation you think it is—that’s incidental at best. It’s perfectly reasonable to say “this chunk of styles is about <em> elements; and when they’re inside <li>, do this”. The specific example you’ve given is also unrealistic with all three rules touching the same property in this way and two mutually exclusive (that is, li and em cannot both match, in any DOM), and I wouldn’t want it written with nesting at all, but rather like this, for much-increased clarity:

  li {
      color: blue;
  }
  em {
      color: green;
  }
  li em {
      color: red;
  }

Hmm, thanks for the food for thought. In my use of CSS, I rarely come across situations that would call for this, but I'll pay more note to the possibility they might come up.