Semantically both ways are not identical. *const T guarantees that the parameter will have the identity of the passed value, T does not. This can make a real difference, although mostly, it won’t.
That last part being some of the problem, but not all of it. There was a conversation here awhile back about the difficulties of forcing Zig to make a copy of a struct, and why this can matter, it’s less to do with parameters and more to do with return values: but a parameter and a return value are sometimes one and the same.
Worth pointing out that for one central optimization, inlining, low-level languages, Zig included, do offer the ability to force the issue one way or the other. I do think that “same memory region” and “different memory region” represents another case where code should be able to insist on either outcome, and in status quo, it’s tricky to consistently get the latter.
I suggested a @copy builtin as a brute-force solution, but it would be nice to have a more elegant answer to this problem and the aliasing issues which prompt it. This one is a “trust the plan” sort of thing for me, Andrew has said a few times that he has some good ideas for how to solve the aliasing problem, and that’s enough for me for now.