https://stackoverflow.com/questions/76847905/what-are-the-reproducible-and-unsequenced-attributes-in-c23-and-when-sh

"Effectless restricts what state a function can modify. If any non-local state is modified, this can only happen through pointers passed to it."
disallow changing global variables

"Stateless means that static or thread_local local variables cannot be non-const, and cannot be volatile."

"Independent means that all calls of the function will see the same values for global variables, won't change global state, and won't change any state through pointer parameters."
can only access const globals
all parameters const
no const_cast
no mutable

Even if a compiler can't guarantee all of the properties of effectless, idempotent, stateless and independent with varying degrees of success, what guarantees can be given is of benefit and reduces chances of errors when implementing these functions.

Reproducible functions should only be able to call other reproducible and unsequenced functions.
Unsequenced functions should only be able to call other unsequenced functions.

Compilers need to track these properties for functions similar to how it is done for constexpr and consteval functions.

In addition to developers promising compilers, developers want promises from compilers.

Why!

F.8: Prefer pure functions
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f8-prefer-pure-functions
While you might point out that it says "Enforcement Not possible."
It is really, partially possible given the above checks.

These attributes are similarly related to the following and as such have similar benefits.

F.15: Prefer simple and conventional ways of passing information
F.16: For “in” parameters, pass cheaply-copied types by value and others by reference to const
F.17: For “in-out” parameters, pass by reference to non-const
F.20: For “out” output values, prefer return values to output parameters
F.21: To return multiple “out” values, prefer returning a struct
CP.2: Avoid data races

If we had guaranteed results in addition to guaranteed compiler checks then there would be safety benefits for non constexpr functions which is something trying to be achieved via various proposals for constexpr.

"Because the function is [[unsequenced]], ... the compiler could even decide to evaluate square(2) just once at program startup."

If the return was const then that would effectively be an object that is both memory safe and thread safe or at least a high degree of both.

P.10: Prefer immutable data to mutable data

I.2: Avoid non-const global variables

ES.50: Don’t cast away const

CP.2: Avoid data races

CP.3: Minimize explicit sharing of writable data

Con.1: By default, make objects immutable

Con.2: By default, make member functions const

Con.3: By default, pass pointers and references to consts

Con.4: Use const to define objects with values that do not change after construction

Con.5: Use constexpr for values that can be computed at compile time