If they're seriously considering the latter two options for us to be stuck with, that's very concerning, and I'll be nervous about the whole affair until something definite rolls out.
Of course, it might be that the syntax authors foresaw some future problems that I don't, but their arguments aren't provided.
In fact, I don't even see why the `@nest` marker is necessary at all. The W3C draft says, “Some valid nesting selectors, like `.foo &`, are disallowed”—but why? They introduced the `&` marker to tell nesting rules apart from anything else, but then it turns out that they can't do that with the marker either? See `&` anywhere in the selector, realize it's a nesting—how much lookahead is needed for this? `&` can't be in a property name or media rule, can it? Surely there's a reason for this constraint, only I can't figure it out—granted, I barely know anything about implementing a CSS parser.
(Update: text cited by @pointlessone notes that a nest-selector might look like `color:hover & something`, which is indeed quite wacky and apparently befuddles the parser.)
Also, philosophically, a more-verbose marker like `@nest` would help avoid the growth of ascii salad in the syntax (the way that Python and Lisp avoid it, compared to Bash and Perl)—specifically if the marker was used instead of both `@nest` and `&` together in those proposals. However, it's probably not such an issue in regard to a feature that's gonna get plenty of exercise and is practically core functionality.