1) Both the C # specification and the CLI specification allow this.
The C # standard says that
The source file is an ordered sequence of Unicode characters.
and
The identifier in the corresponding program must be in canonical format defined by the Unicode Normalization Form C formula, as defined by Unicode Standard Appendix 15. The behavior when an identifier is encountered that is not in the Normalization Form C is determined by the implementation; however, diagnosis is not required.
The CLI ECMA standard has the following:
I.8.5 Naming
Names are assigned to entities of the type system so that they can refer to other parts of the type system or type implementations. Types, fields, methods, properties, and events have names. As for the type system, values, local residents and parameters have no names. A type system entity is assigned one name (for example, there is only one name for a type).
I.8.5.1 Valid names
All name mappings are performed byte-by-byte (for example, case-sensitive, independent, also known as code comparison). If the names are used to access the built-in VES function (for example, the class initialization method), there is always an accompanying indication of the definition so as not to create any set of reserved names.
An important transition follows:
CLS Rule 4: Assemblies must follow Appendix 7 of Technical Report 15 Unicode Standard 3.0, which defines the set of characters allowed to run and included in identifiers available on the Internet http://www.unicode.org/unicode/reports/tr15/tr15-18 .html Identifiers must be in the canonical format defined by Unicode Normalization Form C. For CLS purposes, two identifiers are the same if their lowercase mappings (as indicated by Unicode are language-sensitive, one-to-one lowercase mappings) are the same. That is, for two identifiers that are considered different within the CLS, they must differ more than just their case. However, in order to redefine an inherited definition, the CLI requires the use of exact coding of the original declaration.
[Note: CLS (consumer): you do not need to consume types that violate rule 4 of CLS, but must have them to allow access to named elements that use one of their keywords as a name. CLS (expander): no need to create types that violate the CLS 4 rule. Provides a mechanism for defining new names that obey these rules, but are the same as the keyword in the language. CLS (framework): you should not export types that violate the CLS 4 rule. Avoid using names that are commonly used as keywords in programming languages.
2) There should be no impact on performance. The CLI rules state that name matching should be done using Unicode language-insensitive mappings, which means that matching two names requires conversion to a sequence of Unicode codes. If a compiler or runtime is chosen to store this information in variable-length encoding, such as UTF-8, and convert to code points on the fly, then there will theoretically be some kind of performance difference; practically I donโt expect any implementation for this, or a difference in performance that can be measured if they did.
Note that CLS Rule 4 states that โto redefine an inherited definition, the CLI requires the use of the exact encoding of the original declarationโ, which makes a specific limitation on rewriting names. But since this is not a universal requirement, you still need to "convert everything to code points before comparison."
3) Again, this is in the CLI specification, so the language should do it.