> My point was about the expressiveness of bridgeProvider.canProvideBridgeFor vs a null check.

I'm not sold about that being expressive at all. When I see such a state-checking method that I'm supposed to invoke first, all kinds of questions arise, like "will the answer stay consistent?" "is this service implementor immutable?" and all other nasty things you have to deal with. Since we name it "xProvider", I think any experienced programmer will have some degree of paranoia about the behaviour of the system he's dealing with, and he would likely want to check for _null_ anyway just to make sure, because the "expressive API" confused him. As alternative, you have the beauty of a single atomic statement, and need to understand about the semantics of a single method rather than about the interaction and intended relation of multiple methods.

Let's agree that we clearly had different experiences and have been exposed to different programming paradigms, but my point is that if you bring such dicussions to the path of "clearly more expressfull" or "more readable" it's a very debatable path. Of course I love readability, but that this is a concept strongly related to habits, as we don't like getting out of our comfort zones, but we might have wrong habits, so I find it useful to challenge my own "readability opinions" too with real world needs.

To make a far-fetched example, but possibly real, let's say we want to support OSGi, and that a BridgeProvider implementation is actually a composite of multiple other ones. With OSGi one of the elements of the composition could be "stopped", making a bridge unavailable. The API you propose would be not fit to support such a scenario.
We don't have plans to do this in practice, but still such things exists and so someone attempting to understand the API would need to be aware of us not going to do such a thing. I.E. there are hidden assumptions in your proposal, which would require additional documentation -> not expressive.