It used to be that the 3-arg slice operator didn't exist, so the spec as written was correct. With the 3-arg slice, it isn't technically true any more; as you showed you can construct smaller slices.
Not sure if it would be worth updating the spec, though. It isn't a formal spec. The concept being described is still correct.

https://golang.org/ref/spec#Slice_expressions describes

a[low : high : max] constructs a slice of the same type, and with the same length and elements as the simple slice expression a[low : high]. Additionally, it controls the resulting slice's capacity by setting it to max - low.

So the capacity of a[1:2:3] is 3-1=2.

I think "the sum of the length of the slice and the length of the array beyond the slice" is still correct. You can think the slice expression down-sizes the underlying array.

@cherrymui I disagree.

The actual situation, as determined experimentally using go1.17, is:

arr[0]   before the slice
arr[1]   slice[0]
arr[2]   slice[0:2:2][1] (beyond len(slice) but still ok since 1 < cap(slice))
arr[3]   after the slice
arr[4]   after the slice

If you interpret "beyond" as meaning the same as "past len(slice)", cap(slice) would include indices 1, 2, 3 and 4, which would result in cap(slice) == 4, but it is actually 2.

If you interpret "beyond" as meaning "outside slice[0:len(slice)], on both sides", cap(slice) would include indices 0, 1, 2, 3 and 4, which would result in cap(slice) == 5, but it is actually 2.

In both cases, the spec does not provide a recipe for calculating the actual cap(slice), that's why I asked for clarification.