One of the things which we introduced with the previous interim release was the concept of server pool.The admin can have a combination of disparate set of boxes - solaris sparc/x86, linux and logically combine them to create a single XMPP deployment.Ofcourse, one deployment could support multiple hosted domains - so typically it is a single deployment : not really a single domain which is hosted on a pool.

For the purpose of minimising internode communication, we have also introduced to concept of an xmpp aware load balancer called redirect server.The actual redirection mechanism is an spi and can be customized, but there are a bunch of out of the box methods - including ones which allow for roster based logical grouping of contacts to nodes.The server pool will redistribute any new load across itself in the face of failures ... So, introducing redundency into the pool not only helps in performance of a single node under normal operation, but allows the pool to operate smoothly when you are faced with network, power, etc outages.

Taken together this results in some interesting usecases.
There is minimal network overhead and yet high degree of failover and scalability can be achieved - we have not really tested to reach the limits of how 'large' a server pool can be .... This essentially means that a service provider can not only support a large number of hosted domains, but also provide high availability for all of them with a single deployment.
As far as the end user is concerned, there is no difference whether he is talking to a server pool or to a single server: the behaviour is uniform and spec compliant.
If you consider the distributed nature of features like pubsub, muc, etc in the server pool - it essentially means that you do not have the concept of failure: unless every node in the pool goes down that is
So essentially, you can use the server as a near-realtime messaging middleware with very high availability and scalability.

And yes, the next release we have does include expirimental support for caps and pep at the server and in client api ... might not be the latest version of the spec though. But developers wishing to hack at it are welcome : this impl is not very rigourously tested - so I am not going to popularise it , but we have used it for avataar and seen it working beautifully !
The api which is hosted at collab project of netbeans has the client side support for this (:pserver:anoncvs-AT-cvs.netbeans-DOT-org:/cvs , collab/service/src/org/netbeans)
Btw, did I mention that we have always supported privacy lists ?