did you consider a customizer instead, to allow choice of either replacing or enhancing the default predicate?

I realize it's not the friendliest API, but we've found the pattern really useful in AutoConfigurationCustomizer

and later use something like this

    static class MyFunction implements Function<Predicate<IOException>, Predicate<IOException>> {
        private Predicate<IOException> newPredicate = e -> {
            return false; // logic for  my retryable condition
        };

        @Override
        public Predicate<IOException> apply(Predicate<IOException> defaultPredicate) {
            /**
             * use this statement to extend
             */
            return newPredicate.or(defaultPredicate); // extend


            /**
             * or this to override
             */
            return newPredicate;
        }
    }

it depends how many users will want to extend it. I started the PR quickly with a thought that I need to extend rertry policy, but after some time I realized if a user wants to change the default policy it's ok just to override.

but pls tell me if you think it's nice to have the enhance option for it and I will cover it in this PR and next PR.
Please note that I also have a plan to change the defaults for retryable exception.

The advantage of a predicate customizer is that you can do things like:

• return defaultPredicate.and(..)
• return defaultPredicate.or(..)

If you're just wholesale overwriting the default predicate, you don't get anything from having a customizer:

• return myCustomPredicate

This benefit is somewhat diminished if we make the default retry predicates accessible as part of our stable API (related to #6970), in which case, the and and or cases can be achieved without a customizer by referencing the default predicate API.

I realize it's not the friendliest API

This is the key bit to me. I'd say that API ergonomics feel really foreign to someone who hasn't written a AutoConfigurationCustomizer. That pattern doesn't show up anywhere else in our API.

I'd say that API ergonomics feel really foreign to someone who hasn't written a AutoConfigurationCustomizer. That pattern doesn't show up anywhere else in our API.

good point