我认为g-typexparse参数是绝对必要的，应该在 LaTeX 内核中直接支持，而不是像现在这样被官方弃用。如果您不同意我的观点，请向我解释如何在没有它们的情况下使以下界面工作。（以下语法遵循语义，但现在不用担心这个。）
假设我们想要一组对应于变量我们正在使用。变量A将被称为\va，变量b将是等。每个变量将支持可选的 keyval 语法，为此\vb使用可选的括号是很自然的。因此，到目前为止我们的语法是[...]
\va[<keyval syntax>]
\vb[<keyval syntax>]
...
因此，典型的数学方程式看起来应该是这样的：
\va[power=2] + \vb[power=2] = \vc[power=2] % this should print a^2 + b^2 = c^2
到目前为止一切顺利。然后我们遇到一个问题，许多变量也可以用作功能.例如，变量X可能取决于变量吨，所以我们可能想写X（吨）。事实上，这种情况经常发生，以至于区分变量和函数都很麻烦。所以让我们一致同意，从现在开始，函数只是变量的一个特例。总之，所有变量都需要能够接受参数。
查看标准 TeX 语法，变量带参数的最自然语法是
\va[<keyval syntax>]{<argument>}
\vb[<keyval syntax>]{<argument>}
...
现在我们该如何实现这个目标呢？
第一个坏主意：使用m-type 参数
我们当然可以使用m-type 参数。但是上面的等式突然变成了
\va[power=2]{} + \vb[power=2]{} = \vc[power=2]{} % this should print a^2 + b^2 = c^2
这感觉很多{}不太自然。我们必须在我们使用的每个变量后面都写上，这非常麻烦。此外，想象一下函数的值本身就是一个函数，这种情况经常发生（没有它你就无法进行范畴论）。我们应该如何F(f)(x)使用这个解决方案进行输入？
太好了，那我们就放弃这个想法吧。
第二个糟糕的想法：使用d()-type 参数
接下来，我们可以尝试在普通括号中使用可选参数，即类型的参数d()。然后我们的语法变成
\va[<keyval syntax>](<argument>)
\vb[<keyval syntax>](<argument>)
...
我承认这是一个诱人的解决方案，特别是因为数学参数通常也使用括号打印。然而，至少有两个大问题：
- 该语法与一般的 TeX 语法不太相符。使用括号作为命令参数感觉不常见且不熟悉。在 TeX 中，我们习惯在
[...]和中输入参数{...}，第一种类型主要用于选项，第二种主要用于“实际”参数。我们习惯于(和)表示方程式中的括号；它们作为命令构造的一部分通常没有任何句法含义。 - 嵌套命令可能会导致问题。当然，
xparse通常可以很好地识别嵌套命令。但有些东西xparse无法帮助我们。例如，假设我们设置变量\vf，使其参数在投影坐标中打印，即\vf(\va,\vb,\vc)打印f[a:b:c]。现在如果我输入\vf(\va,\vg(\vb,\vc))，它将扩展一次为f[\va:\vg(\vb:\vc)]，现在\vg将不再将\vb和识别\vc为两个不同的参数，而是识别为一个参数\vb:\vc。
第三个糟糕的想法：使用两个可选的o类型参数
那么语法就变成
\va[<keyval syntax>][<argument>]
\vb[<keyval syntax>][<argument>]
...
我想我们都看到了这个解决方案的问题。如果你只想打印a(x)，而没有 keyval 语法，那么现在你必须输入\va[][\vx]，这感觉不自然。此外，这种语法与第二个糟糕的解决方案有相同的嵌套问题。
唯一剩下的解决方案：使用g-type 参数
唯一剩下的解决方案是在括号中使用可选参数，即类型的参数g：
\va[<keyval syntax>]{<argument>}
\vb[<keyval syntax>]{<argument>}
...
然后我们可以输入\va[power=2]和\va{\vx}，两者都感觉同样自然。没有嵌套问题，不需要不断打印任何类型的额外空括号。而且语法自然地融入了一般的 TeX 语法。你可以F(f)(x)通过输入 来书写\vF{\vf}{\vx}。
我的问题
正如我上面所说，如果您真的认为g-type 参数应该被弃用和避免，就像当前的 LaTeX 政策一样，请为我提供解决此处提出的问题的替代语法。否则，不将它们包含在 LaTeX 内核中是错误的。
答案1
这是一个接近元问题或者基于观点的问题，但我认为可以回答两个方面。
为了讨论而不是直接问题，TeX-sx 不是一个很好的平台。因此，在这里讨论这个问题可能不会有太大效果：我们拥有的“最好的”是一个专门的聊天空间。更一般地说，与开发人员讨论他们的代码最好是通过或多或少直接与他们沟通。就 LaTeX 团队而言，LaTeX-L 邮件列表是值得一去的地方。
关于 中的弃用问题xparse，需要注意的是，大多数想法都被转移到了内核。其余的想法保留在存根中xparse。在撰写本文时（2020 年 11 月），有一些小的技术重新安排尚未完成，但基本上存根已被冻结。如果存在彻底的错误，它们将被修复，但不会有重大添加。另一方面，存根不会被删除：xparse现在已经广泛使用了很多年，虽然团队认为某些方面不值得转移到 LaTeX 内核，但删除它们会破坏太多的包/文档，这不是一个合理的做法。