Question: Can `previous.kind == akind` be reached in `backtrackToNextNodeKind()`?

While reading pkg/route/tree.go, I noticed the following logic in backtrackToNextNodeKind():

```
if previous.kind == akind {
nextNodeKind = skind
} else {
nextNodeKind = previous.kind + 1
}
```

From my understanding, the previous.kind == akind branch appears to be unreachable in the current router implementation. However, I may be missing some edge case, so I would appreciate clarification from maintainers.

Evidence
1. Control-flow analysis

The only path that enters an akind node appears to be:

if child := cn.anyChild; child != nil {
cn = child

...

res.handlers = cn.handlers
break
}

Once an akind node is entered, the search loop exits immediately via break.

As a result, execution does not appear able to reach the later call to:

backtrackToNextNodeKind(akind)
2. Runtime verification

I temporarily added:

if previous.kind == akind {
panic("unreachable: backtrack from akind should never happen")
}

and ran:

go test ./... -count=1

The entire Hertz test suite passed successfully and the panic was never triggered.

3. History inspection

Using git blame, this branch appears to have existed since the early version of the file.

This made me wonder whether it is a defensive transition inherited from an earlier implementation, or whether there is still a valid route matching scenario that can reach it today.

Question

Is there any route configuration or backtracking scenario in which:

previous.kind == akind

can still be reached in the current implementation?

If not, would the following simplification be valid?

nextNodeKind = previous.kind + 1