You can get even more performance if the bound-checks* are eleminated.
_n is the length of the path, so use this information for the JIT.

Removes the bound-checks.
The same could be done at other places -- and get rid of the (unnecessary) _n field (makes the parser 4-bytes smaller, not much but a little bit and it harms perf as the JIT can't remove bound-checks).

* the JIT needs to emit these bound-checks in order to prove the access to the array is within bound. Only if the JIT is sure the access won't be outside, these can be removed.

I already tried removing the bound-checks but I didn't see any perf gain. Though I didn't use the uint cast. I will try to benchmark it again with the cast and I can open another PR with your suggestions if you'd like.

The uint-cast is essential for the JIT, as any negative value (which is allowed by int) will be > int.MaxValue and so for sure outside the bounds. Then when the JIT sees that index is non-negative and < length it's OK to elide the bound-check.

Though the JIT could be improved in that area (and it is).

One cmp can be saved by

The char between [ and ] is \, so if the backslash could be treated as (implicit) special char, then another cmp could be saved.

With the benchmark above I get these numbers:

| Method | ch |     Mean |     Error |    StdDev |   Median | Ratio | RatioSD |
|------- |--- |---------:|----------:|----------:|---------:|------:|--------:|
|    New |  . | 1.708 ns | 0.0429 ns | 0.0380 ns | 1.709 ns |  1.00 |    0.00 |
|   New1 |  . | 2.255 ns | 0.0442 ns | 0.0392 ns | 2.247 ns |  1.32 |    0.04 |
|        |    |          |           |           |          |       |         |
|    New |  / | 1.683 ns | 0.0661 ns | 0.0707 ns | 1.670 ns |  1.00 |    0.00 |
|   New1 |  / | 1.690 ns | 0.0459 ns | 0.0430 ns | 1.687 ns |  1.00 |    0.06 |
|        |    |          |           |           |          |       |         |
|    New |  [ | 2.334 ns | 0.0830 ns | 0.0693 ns | 2.326 ns |  1.00 |    0.00 |
|   New1 |  [ | 2.259 ns | 0.0364 ns | 0.0323 ns | 2.257 ns |  0.97 |    0.03 |
|        |    |          |           |           |          |       |         |
|    New |  ] | 2.001 ns | 0.0623 ns | 0.0583 ns | 2.011 ns |  1.00 |    0.00 |
|   New1 |  ] | 1.760 ns | 0.0729 ns | 0.1473 ns | 1.691 ns |  0.89 |    0.12 |
|        |    |          |           |           |          |       |         |
|    New |  a | 1.912 ns | 0.0278 ns | 0.0217 ns | 1.911 ns |  1.00 |    0.00 |
|   New1 |  a | 1.430 ns | 0.0565 ns | 0.0528 ns | 1.437 ns |  0.75 |    0.03 |

Only the case . is slower, as in New this is the first char to be tested against. All other cases show some improvements.
To have a clear view if the regression for . is acceptable or not, one should benchmark with real pathes to make it more realistic. Also with these kind of benchmarks the cpu's branch predictor is trained well, so it will know which branch to take, which isn't very realistic either. So micro-benchmarks are fine, but not necessary reflect the usage of the method / type.

Here is a benchmark with only a call to PathParser.Parse:

I tried using values that represents real-word scenario. If you have other values that you'd like me to try, I can run another benchmark.

Here is the results with your suggestion:

It seems a bit worse on my machine.

Thanks for doing the benchmarks. So I think it's best to keep your code as the numbers don't show a clear winner, but your code is more intuitive and readable.

We should just make sure that the most common special-char comes first -- I don't know which one is the most common.

I don't know either which one is the most common but I suspect the most common is the ".". I've never seen a usage of "/". I don't think a path includes many "[" and "]" since it's for an indexer and I don't think it is common to have multiple indexer on the same path.

We have a rather large WPF app with about 70 projects, none of which use / and I found 29 instances of .. This doesn't include any of the XAML brought in thru Telerik controls.