I think the key word is otherwise

In and out may be the same slice but otherwise should not overlap.

Same slice is ok, and it that case they'll overlap (obviously), but otherwise they shouldn't overlap.

Huh? I don't think that helps.

How about

in and out must overlap entirely or not at all.

if in and out overlap, they must be identical

is how it's usually worded in BoringSSL

The intent is to describe that there are only two valid situations:

1. in and out are the same slice.
2. in and out do not alias at all.

Other configurations (i.e. in and out partially overlap) may not produce the correct result. As Martin notes, we often use a slightly different wording in BoringSSL. I fear that I'm too close to the trees to have a valid judgement about what would be clearer so someone else is free to pick something and change the wording.

Maybe
out[0:1] and in[1:] must not overlap.

I think this is accurate but a little obscure.

We should also put that text in the cipher.Stream.XORKeyStream docs.

The current text probably means this, but leaves too much open to interpretation, and implementations are already more strict anyway:

Dst and src may point to the same memory.

For the sake of breaking the bikeshed, I'm going to CL "must overlap entirely or not at all" tomorrow unless anyone objects.

Change https://golang.org/cl/61133 mentions this issue: all: make overlap rules wording consistent

Change https://golang.org/cl/61132 mentions this issue: crypto/cipher, crypto/rc4: make overlap rules wording consistent