To what capacity appends grow slices is not defined in the language spec and could even change from release to release. Therefore its good to not depend on the actual implementation of how much they grow. Is there a specific reason why they should be kept consistent?

That said I wouldnt be surprised if some tests/code breaks having made assumptions as how far reflect.Append grows slices so this will add some churn when changed.

I agree that it is not a bug. The weak reason to keep them consistent is reflection should try to be consistent with non-reflection.

Is it possible that reflection also could call the runtime slice-grow implementation?

Something like this happens in a couple places, not just with reflect. For example:

package main

func f(s string) {
	a := []byte(s)
	b := []byte(s)
	println(cap(a), cap(b))
	sink = b
}

func main() {
	f("foo")
}

var sink []byte

Produces:

32 8

Because one is a stack allocation and one is a heap allocation.

I don't think there's any value in being consistent. At least, there is value in intentionally allowing ourselves to be inconsistent.

Yes, I agree it is not a big problem, or even a problem.