This is why you should randomize all behaviors which should not be depended on. Change things quickly and often if you're not making any promises.
Not only one has to be actively aware about all the behaviors they don't document (which is surely not an easy task for any large project), they have to spend a non-negligible amount of time adding randomness to it in a way that would still allow all the internal use cases to work cohesively. This means you spend less time on doing something actually useful.
Instead of randomizing, it should be sufficient to just figure out the semantics for clearly communicating what's the public APIs and stable, and what's internal and subject to change at whim. And maybe slap a big fat warning "if something is not documented - it's internal, and $deity help you if you depend on it, for we make no guarantees except that it'll break on some fine day and that day won't be so fine anymore". Then it's not your problem.
that's why you prevent it from ever coming into existence if you can
Go's implementation of JSON format for protobufs also does this: https://protobuf.dev/reference/go/faq/#unstable-json
> To avoid giving the illusion that the output is stable, we deliberately introduce minor differences so that byte-for-byte comparisons are likely to fail.
package main
import "fmt"
func main() {
m := map[string]int{"a": 1, "b": 2, "c": 3}
for k, _ := range m {
fmt.Println(k)
}
for k, _ := range m {
fmt.Println(k)
}
}
c
a
b
a
b
c