The older crypto packages were written with the assumption that #395 would be resolved. However, that hasn't happened and using array pointers is kind of a pain without out. Ed25519 is newer and so uses a different convention.

If anything, unless #395 is going to be fixed, I'd suggest converting the older packages to taking slices rather than converting ed25519 to take array pointers. (However, I think the benefits of a stable API outweigh that consideration.)

Could you give me a hint what the problem with array pointers for keys is?

It seems to me that the lack of a fix for #395 is an argument against slices (since conversion to slice via [:] is simple, but the opposite impossible).
Looking at the internals of ed25519 (as an example), the lower level code seems to use arrays anyway and gets cluttered with copy-conversions to arrays and checks like "if l := len(publicKey); l != PublicKeySize"
For the user it has the downside that sizes are much less obvious and not compile time checked.

I understand if you want to keep the API stable for this one, but for future additions I don't see the redeeming features of key slices.

Keys with variable size are a completely different situation of course.

I think the discussion on #395 covers it pretty well: if you're throwing bytes around in Go, you're probably using []byte. E.g. a message from the network will be a []byte and the signature might be at the end of it. For APIs which take array pointers you then have to have a local [64]byte for the signature, copy the signature from the message to the local variable, and then pass a pointer to the variable to Verify. It's sadly clunky.

I agree about the benefits of array pointers which is why I initially used them, but it was in the expectation of being able to cast from slices to array pointers to avoid that clunkiness.

(p.s. to be clear: if adding signature support to the nacl package, I think consistency with the existing API in that package is a decent reason to use array pointers there.)

Thanks I see your point now. I'm not sure sacrificing the more elegant and safe interface is worth the potential convenience here, but that's obviously a matter of opinion.

Maybe the crypto package should just provided a set of conversion functions that use unsafe:

func Arr64(s []byte) *[64]byte
func Arr32(s []byte) *[32]byte
...

That would be about as convenient (and safe) as a proper fix to #395. But I guess that's a separate issue.