But if they were adding symbol support, it would have to work for accessing actual members, not for just faking string indexed members as if they were members. Symbol support would let you do things like this:

  public double GreatestExtent {
    get {
      Symbol directionOfGreatestExtent = $X;
      if (this.Y > this.X) directionOfGreatestExtent = $Y;
      return this.#directionOfGreatestExtent;
    }
  }

(I'm making up some sort of syntax on the spur of the moment here)

Clearly this can be written easily enough without symbol support, but you could argue that the intent of the logic is clearer here than it is in some alternative approaches.

But the thing is that the kind of symbol they've given us isn't a syntax where $foo is a literal which means 'a symbol which accesses the member foo on the target', but instead a syntax where $foo means 'a symbol which accesses the indexer on the target which takes a single string as an argument and passes the string "foo" to it' - just like ["foo"] does.

If I have my co-ordinates stored in a dictionary, I don't need this symbol support to be able to write that kind of logic:

  public double GreatestExtent {
    get {
      string directionOfGreatestExtent = "X";
      if (this["Y"] > this["X"]) directionOfGreatestExtent = "Y";
      return this[directionOfGreatestExtent];
    }
  }

In fact, it isn't even possible to really make use of the new $key support in that scenario because, as I said, they're not providing any mechanism to store the $key value and reuse it; you're forced to mix string literals and these key symbols:

  public double GreatestExtent {
    get {
      string directionOfGreatestExtent = "X";
      if (this.$Y > this.$X) directionOfGreatestExtent = "Y";
      return this[directionOfGreatestExtent];
    }
  }

I don't see how being able to make that change to this code is a step forward...