There has been a long-standing issue with the Vault charm in environments like AWS which have different subnets for different AZs which boils down to the Vault charm needing to determine what address it should advertise to a given relation, where extra-bindings might be used to "label" different network(s) as public ("external") or private ("access") [1], but not having enough info in certain circumstances to be able to determine that. Arguably, Vault's usage of extra-bindings in this way is an attempt to work around the fact that the current implementation of spaces means that all relations on a given endpoint are forced to use the same space, rather than being able to specify it on a per-relation basis [2].
The place where CK runs up against this is whenever we try to use Vault on AWS, since each AZ on AWS has its own subnet, when the Vault charm tries to match the ingress-address for the related app to one of the subnets for one of the extra-bindings, there is no match because the related app is in a different AZ and thus on a completely different (but routable) subnet [3]. The current attempt to fix this for CK [4] is blocked because it doesn't work in the case where the bindings are used by the Vault charm in the way they are intended. Unless we can find a solution, this means that the Vault charm can basically never be used on AWS.
[1]: https://bugs.launchpad.net/vault-charm/+bug/1826892
[2]: https://discourse.charmhub.io/t/multiple-space-bindings-per-endpoint/1999
[3]: https://bugs.launchpad.net/charm-kubernetes-master/+bug/1843809
[4]: https://github.com/openstack-charmers/charm-interface-vault-kv/pull/6
Not really for 2.9 but likely to be part of a discussion for next cycle.