配置中的数组不是一个“初级”项目，而是一大堆蠕虫，影响树中的整个命名方案。

谢谢@MitchBradley对于警告……我会看看它是否会很快失败?

但是，您的回复还告诉我，没有朝那个方向进行任何工作，而且现在肯定不支持它。

我只是试一试，然后我们可以看看我能走多远，如果有的话，再判断结果。

如果您将其作为 besc 节点下的数组来执行，则主轴选择逻辑现在有两个级别而不是一个级别。如果你把它作为多个 besc 节点来做，比如

besc:
   blah blah
besc:
   blah blah

然后，当您引用一条路径时，您需要一种方法来区分它们$besc/pwm_hz

如果我们引入这样的东西，它不应该只是作为主轴上的疣，而是作为一个通用功能来完成，它对整体语法有深远的影响，因此兼容性问题、文档要求、支持影响。

如果我们引入这样的东西，它不应该只是作为纺锤上的疣来完成，而是作为一个通用功能，

绝对！正在考虑将实例化逻辑放入GenericFactory（显然是在增强解析之后）。

请不要只是开始黑客攻击。考虑对树管理的多个阶段的影响——解析、转换为 WebUI 配置页面自动生成的 JSON 表示、运行时设置的路径名解析等。

完全不明白您有兴趣这样做?

无论如何，我会尝试破解。在业余时间，我可以随心所欲地浪费可用时间。

如果结果是值得学习和丢弃的东西（编辑：并可能从头开始重做），那对我来说不是问题。
我喜欢迭代代码就像迭代想法一样。在这样的探索阶段，代码只是更明确的想法记录，偶然也可以执行。

基本点是，这实际上改变了树中路径名的语法。语法添加总是意义深远，因为它们引入了以前很普通但现在很神奇的字符。那涟漪贯穿了一切。

如果你开始这个然后发布 PR，那么某人——几乎可以肯定是我——将不得不参与其中——这需要我现在没有的时间——或者忽略它——从社区关系的角度来看这也是有问题的.

底线——如果你首先在其他领域做出贡献，比如处理我们现有的待办事项列表，而不是进入我已经知道会产生深远架构影响的未知领域，我会更高兴。

有一些相关的东西已经在我们的雷达上很长时间了。与其在轴下声明电机——这对于不同的运动学来说会变得混乱——不如单独声明电机，然后在轴和运动学中引用它们。uarts 也有类似的问题，它的声明实际上应该从使用它们的节点中分离出来。

这与您的问题相关的原因是它为同一类型的多个对象引入了命名问题。