The first example used this signature:

  func one[S []E, E any](s S)

Why would you chose this signature instead of:

  func one[E any](s []E)

This is not a rhetorical question. My career veered away from go shortly after 1.18 released so I haven’t done much with generics.

[]any isn't "any slice", but rather "a slice of some type, and that type could be anything."

It's not just a detail of the underlying runtime; there are very real, semantic problems that would occur if two(s) compiled. Consider what would happen if instead of just returning its input, two([]any) modified it:

  func two(s []any) {
   s[0] = "hello"
  }

That's certainly allowed. Now imagine you had:

  someInts := []int{1, 2, 3}
  two(someInts) // this won't compile

It's a good thing that second line doesn't compile, or your []int would contain a string element.

nonmeasurable sets

Was expecting food taxonomy: when is a slice of food not a slice of food?

(Not go-lang.)

See cube rule of food identification for actual discussions on food taxonomy.