Unexpected SemanticModel responses related to ValueTuples when it involves a nullable element

[Liander]

Consider the types reported for these different deconstructions and ValueTuple related access. See screenshot:

sharplab.io

1. What I am really trying to do is to get the RHS type at any assignment of a nullable typed variable. The nullable annotation info seems to get lost in various places as I am trying to show in the above examples.

2. The above is what you get from API calls to GetSymbols for the hovering token. What API should I use to get the type for the RHS when assigning a variable?
   Expected: GetTypeInfo(assignment.Right) should get the type (with annotations) for ValueTuple assignments and GetDeconstructInfo should get it when a Deconstruct call applies (which it does). Even better if that is embedded into an operator on the designated variable so that a custom variable to argument mapping is avoided.
   Actual: The nullable annotation seems to get lost, just like what happens in the examples above.

3. Example A explores the fact that the compiler sometimes makes use of its knowledge of the nullability of a reference type and sometimes it doesn't. It makes the user question its code and/or question the tooling. To model the effectively inferred nullability of a reference variable 's' you have the states:

• 's' is nullable, inferred at declaration.
• 's' is nullable, inferred from a reassignment. (Implying it's not nullable at declaration)
• 's' is not nullable, inferred from all assignments.
  I think it should be considered to have that inference knowledge included in the symbol from the semantic model. That would make it easy for analyzers to do things like saying when a nullable reference (such as string? s = "Hello") can be declared with a non-nullable type instead. And for tooling like QI to show a description of the actual nullable inference when its contradictory to its presented symbol (the 'var' case) and provide any symbol presenter the choice whether to show the symbol with its effectively inferred nullability or not. (See also Behavior of "var" quickinfo and nullable reference types #63959)