If you read a number of writeups of the Go's new support for generics, which is expected to be in Go 1.18, you'll find them mentioning a constraints package in the standard library (for example, Generics in Go). The constraints package is there to give people a pre-defined set of names for various type constraints, like 'only integer types'. Go itself defines two built in constraints, 'any' (which allows anything) and 'comparable' (which allows anything that can be compared for equality); everything else you either have to write yourself using type sets syntax or get from constraints.

Or at least that was the state of affairs until very recently, when the Go developers decided that they didn't want to commit to the constraints package this early in the use of generics. This was discussed in issue #50792, constraints: move to x/exp for Go 1.18, filed by Russ Cox. To quote from the start of that issue:

There are still questions about the the constraints package. To start with, although many people are happy with the name, many are not. On top of that, it is unclear exactly which interfaces are important and should be present and which should be not. More generally, all the considerations that led us to move slices and maps to x/exp apply to constraints as well.

As far as I know, the current version of x/exp/constraints is the same as what was in the Go development source tree until very recently.

On the whole I think this is a good change, because the Go developers take their compatibility promises seriously. Once something is in the Go standard library, its name and API is frozen, so getting both of those right is important. And regardless of what we like to think, people are not always great at either naming or APIs. Sometimes it takes experimentation, actual use, and experience to sort it out, and Go has already had issues with this (most famously context, which was added to the standard library after various APIs that really should take a Context parameter).

The negative side of this change is that it makes life a bit harder and less obvious for people who want to do things with generics that go beyond just a 'comparable' constraint. In turn this seems likely to reduce the number of people doing this, which means that we'll get less such experimentation and use of generics. By making it harder for people to go beyond 'comparable', the Go developers may have made it a self-fulfilling prophecy that people mostly don't. Perhaps this is a good thing, if you want to minimize use of generics in general.

(I'm not sure that the Go developers genuinely like generics, as opposed to just accepting that they're necessary in some form.)

This does show that the Go developers can change their mind about things quite late, since this change comes after the second beta release of Go 1.18. The Go 1.18 version of generics won't really truly be finalized until Go 1.18 is officially released (although major changes seem unlikely at this point because of the amount of code changes that would be required for anything except perhaps disabling generics entirely).