This isn't about aliasing, as the specification notes "If the capacity of s is not large enough to fit the additional values, append allocates a new, sufficiently large underlying array that fits both the existing slice elements and the additional values. Otherwise, append re-uses the underlying array." [1].
I encourage anyone who writes Go to read the specification. I found it very digestible and my code has improved a lot as a result. In this case, for example I can do things like pre-allocate a slice of given and then append to it several times without re-allocations which I sometimes find more semantic when dealing with binary data -- and the reference to the slice doesn't need to change.
I used to think like that: learn all of the quirks and the internals behind them, and you always have an explanation.
With postgres, I always had an explanation why it was doing so much work on every update, and why replication was so hard, and why checksums were impossible to implement efficiently, and why index only scans wouldn't work, and...
After seeing that all of these things were fixed by people who didn't think that way, I changed my mind.
This Go behavior is surprising behavior and non-deterministic. Changing a constant can have some bizarre action at a distance that breaks your code. It affects ordinary code even if the author doesn't care about these details. I really don't see anything good about it even if you do understand it.
I encourage anyone who writes Go to read the specification. I found it very digestible and my code has improved a lot as a result. In this case, for example I can do things like pre-allocate a slice of given and then append to it several times without re-allocations which I sometimes find more semantic when dealing with binary data -- and the reference to the slice doesn't need to change.
[1] http://golang.org/ref/spec#Appending_and_copying_slices