Most op mode commands that use a <node> and a <tagNode> at the same level to define the command behavior when it's called with or without a child can be greatly simplified with the new <standalone> element (T7542).

It's possible when a command only has two use cases:

1. It's called with a child and possibly with arguments after the child, like clear interfaces counters ethernet eth0.
2. It's called without any arguments, like clear interfaces counters ethernet (clear counters for all Ethernet interfaces).

However, there are cases when there are two (or more) command subtrees: one for the child node and one (or more) for fixed keywords.

For example:

• show ip route summary
• show ip route x.x.x.x/y longer-prefixes

Most such cases could be reduced to the simpler problem of standalone behavior if we were ready to add an intermediate keyword, like show ip route to x.x.x.x/y. However, that would break the muscle memory for a lot of users and also break the expectations for people who are coming from different network OSes.

In those cases it may be better to use a more complex mechanism of "virtual children".

For example,

<node name="route">
  <children>
    <leafNode name="summary">
      ...
    </leafNode>
    <virtualTagNode>
      [commands for "show ip route x.x.x.x/y" go here]
    </virtualTagNode>
  </children>
</node>

We should use a different element for those virtual children (<virtualTagNode> in the proposal above) because <tagNode> requires a name and relaxing that restriction is a bad idea — it will make it possible to accidentally write a broken definition with normal, non-virtual tag node missing its name.

The ugly part of it is the representation of the virtual child in the JSON cache that will be used for command lookup and documentation generators.

The only viable (but still ugly) way I could think of is to use a name that cannot be a normal node name, like !tag (de facto, we require node names to start with letters or digits).

{
  "route":
  {
   "children":
   {
      "summary": { ... }
      "!tag": { ... }
    }
  } 
}

Once a reserved name comes to be used this way, we will also need to enforce node name restrictions at build time to ensure they all start from letters or digits so that !tag remains reserved.