这就是我发现的。
我认为毫无疑问，这些名称在 COM 中的二进制级别是合法的，因为 COM 接口的名称是它的 IID，而文本名称只是文档。
在 .NET 方面，相关规范是公共语言基础设施规范（ECMA-335，http://www.ecma-international.org/publications/standards/Ecma-335.htm。）我想知道是 .NET 还是 Mono在上面添加自己的限制——这样做会降低互操作性，但这是现实世界。
第 8.5.1 节介绍了通用类型系统中的有效类型名称，并简单地说名称是使用代码点进行比较的。奇怪的是，它没有说明名称的组成，只说明名称的比较方式。本节由 MSDN 在http://msdn.microsoft.com/en-us/library/exy17tbw%28v=VS.85%29.aspx解释，其中说唯一的两个限制是 (1) 类型名称是“编码为 Unicode（16 位）字符的字符串”，并且 (2) 它们不能包含嵌入的 0x0000。
我引用了关于 16 位 Unicode 的内容，而不是对其进行解释，因为它使用了不精确的语言。据推测，该页面的作者指的是 UTF-16。在任何情况下，ECMA-335 都指定了逐字节比较，并且没有提及 Unicode（关于类型名称），也没有禁止嵌入零。也许.NET 已经偏离了这里的 CTS，尽管我对此表示怀疑。更有可能的是，这个 MSDN 页面的作者在编写它时正在考虑编程语言。
公共语言规范（也在 ECMA-335 中定义）定义了源代码中标识符的规则。标识符与我的问题没有直接关系，因为我的内部类型名称从未出现在源代码中，但我还是调查了它。CLS 是 CTS 的一个子集，因此它的限制不一定是更广泛的 CTS 的一部分。CLS 规则 4 规定标识符必须遵循 Unicode 标准 3.0 技术报告 15 附件 7 的规则 - 请参阅http://www.unicode.org/reports/tr15/tr15-18.html。该文件也有点模糊，因为它提到“其他字母”和“连接标点符号”，但没有定义它们。这有帮助： http: //notes.jschutz.net/topics/unicode/。
ECMA 规范的第 8.5.1 节包含一个非规范性注释，即 CLS 使用者（我想，例如 C# 或 Visual Studio 类型的浏览器）“不需要使用违反 CLS 规则 4 的类型”。我提议的接口名称确实违反了规则 4。该注释似乎暗示有效类型的名称可能违反规则 4，并且 CLS 使用者应该接受流氓名称或安全地忽略它。（Visual Studio 类型的浏览器毫无怨言地显示它。）
所以我提议的类型名称在源代码中通常是非法的。但请注意，第 10.1 节（关于 CLS 中的标识符）说“由于其规则仅适用于导出到其他语言的项目，因此未从程序集导出的私有成员或类型可以使用他们选择的任何名称。”</p>
我的结论是使用字符#@ 是安全的！在我的类型名称中，只要它们保留在二进制域中并且永远不需要出现在源代码中或程序集之外。事实上，它们从未在 COM 服务器之外使用过。
关于面向未来的一句话…… CTS 对类型名称的组成几乎没有什么可说的，尽管有一个名为“有效名称”的部分（第 8.5.1 节）。他们将来可能会改变这一点，但是这个广泛而自由的规范已经邀请我们所有人做我们喜欢做的事情。如果 CTS 的设计者想要为改变留出空间，那么他们肯定会为此做出一些规定，或者至少不那么慷慨。
有趣的是，您似乎发现了 COM 类型命名的漏洞。Microsoft 限制使用字符“#@！” 作为 MIDL 中的标识符，但它们不会在 ICreateTypeInfo 和 ICreateTypeLib 接口中重复该限制。
使用这些字符今天有效，那么风险是什么？
好吧，Microsoft 可以将此视为一个错误，并在下一个版本中“修复”ICreateTypeInfo、ICreateTypeLib、.Net COM Interop 和/或 .Net 类型命名限制。
您正在创建和使用没有任何有效 MIDL 定义的接口。
如果（何时）从 COM 转换到 .Net，您使用的名称可能必须更改。即使您只想在 .Net 中创建适配器类型，您也无法重用任何“无效”名称。
这是否与 Mono 和其他非 Microsoft .Net 兼容技术兼容？
有很多已知的有效名称可以使用（使用类似' _at_'而不是' @'等）以避免任何可能的未来问题。
如果这些对你来说都不重要，那么你可能会没事的。但我怀疑你问这个问题的事实，在某种程度上它对你来说并不“感觉”。
祝你好运。