I suggest you ...

Compliable strings

If you're writing a tracing and logging component you may well want to pass the current method name to your logging component. Rather than hard code it (then forget to change it when you change the method name) you can use reflection and the MethodBase class to retrieve the name:
System.Reflection.MethodBase currentMethod = System.Reflection.MethodBase.GetCurrentMethod();
System.Diagnostics.Debug.WriteLine(currentMethod.Name);
System.Diagnostics.Debug.WriteLine(currentMethod.DeclaringType.Name);
System.Diagnostics.Debug.WriteLine(currentMethod.DeclaringType.Namespace);

In C # 4.5 you can use attributes System.Runtime.CompilerServices.CallerMemberNameAttribute, System.Runtime.CompilerServices.CallerFilePathAttribute and System.Runtime.CompilerServices.CallerLineNumberAttribute for such purposes.

Frequent use of reflection dramatically reduces performance. Using special attributes is a contentious issue. Because attributes inherently are declarative. They obviously do not provide full support for the aspect programming. Thus, we can conclude that C# developers have created next hack for improving programmability.

At the moment, there is another solution of such a problem. You can use expression trees to improve the code readability. This is a very good approach, especially for refactoring, but it may reduce performance.

If during compilation process code item mapping failed, the compiler generates an error.

This feature would allow to write faster and better code. Also should mention the opportunities for effective use refactoring. Likewise, the DLR can be extended. It may be safer and more comfortable to use:
PropertyInfo pi = #`Counter`
FieldInfo pi = #`_counter`
MethodInfo mi = #`Display()`
MethodInfo mi = #`String.Equals(String, String)`

This syntax can be ambiguity in the choice between the field and the property, which can be solved as follows:

The programming language should consist of naturally intuitive and coherent keywords.
The process of the development of language is that it will eventually getting clear and agile grammar.
For example, our programming language has a grammatical shortcoming.
Take the operator "typeof". It is very similar to the method. In this case, it may be a reasonable question.
What type of data of the argument is passed to the operator "typeof" which is very similar to the method?
Right! This is not a data type, and it is unclear what! The same problem have delegates.
We can write the following line:
Func<String, String, Boolean> equals = String.Equals;
The compiler will understand us correctly. It will automatically create a wrapper class.
But understandably the compiler will generate an error if I try to write a following line
Sting str = (String.Equals).ToString();
Obviously initially we had to go the other way. We just had to use dynamic strings:
Type type = `System.String`;
MethodInfo mi1 = `System.String.Equals(String, String)`;
MethodInfo mi2 = `Boolean System.String.Equals(Object, Object)`;
var eq = mi1("a", "b");
Func<String, String, Boolean> equals = mi2;
class A { public Boolean Equals(String str1, String str2) {...}
...
Func<String, String, Boolean> equals = `Equals`;
or
Func<String, String, Boolean> equals = `Boolean this.Equals(String, String)`;
...}
A a = new A();
Func<String, String, Boolean> equals = `a.Equals`;
or `a.Equals`("A", "B");
...
MethodInfo mi = `method: public String.IsNullOrEmpty`;
...
Window win;
PropertyInfo pi1 = `win.Title`;
PropertyInfo pi2 = `String win.Title`;
PropertyInfo pi3 = `private String myClass.MyPrivateProperty`;
PropertyInfo pi3 = `property: private String myClass.MyPrivateProperty`;
...
Assembly asm1 = `mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089`
Assembly asm2 = `assembly:mscorlib`
The scope "assembly" is applied to avoid ambiguous interpretation.

And what if I want to get the string representation.
In this case, you can call the method already known to all:
`method:Boolean this.Equals(String, String)`.ToString(stringFormat)

We can go further, if we assume that all objects of reflection inherited from the base class or interface (IReflection, Reflection). There can be implemented implicit conversion to a string representation:
String str = `Boolean this.Equals(String, String)`;

All of this features provides us with great dynamic opportunities and keeps our code clean.

To improve performance, we may use a compiled string operation for conversion to string at compile time:
String str = @`Boolean this.Equals(String, String)`;

I'm not talking about other enjoyable opportunities:
from `methods:public this` in m
where m.Name.StartsWith("E")
select m;

from `properties: this` in m
where m.Name.StartsWith("E")
select m;

from `properties:private String this{get;}` in m
where m.Name.StartsWith("E")
select m;

I would like to express my own views on this proposal. Of course, some might support the option of creating pseudofunction like nameof(...). This programming language has already such "miracle" named typeof(...). But if it looks like a function, It should behave like function. What type of its argument? That's why I would not want to have this kind of the cornerstones in my garden. Programming language should be as small as possible such hacks.

This prevents a source code full text search to find the trace statement.

It adds extra complexity to the C# .net environment. Method names are largely unchanged after the initial production release and any refactoring would need to take into account renaming the method name hard-coded in trace message strings.

There should be both a method name and full class name including name space defined by the compiler as a string macro variable. These could be used if needed a compile time.

Implementation of the DLR-query expression (DLR-QE) feature is extremely necessary! But the symbol '#' may be replaced by a question mark '?'. It is also possible to use the dot symbol '.' for referring to the current context. The concept of scope can be used to specify nested contexts: