The Mulberry email client from Cyrusoft supports ACAP reasonably well. It doesn't use NOTIFY, so you'll only get a snapshot of data, but it's fine for use as a roaming server, as it'll store addressbooks and configuration on the server, rather than on the client. That said, configuration isn't accessed through the current drafts on the subject, so interoperability with those that do is limited, and there's a few gotchas.
Throughout, ACAP support is limited to basic SEARCH commands. Given the current state of the majority of ACAP implementations, that's no bad thing, but it does mean that should, say, your addressbook change behind Mulberry's back, Mulberry won't notice for a while. There's also some bugs, I think:
Some attributes of entries in /addressbook/ are supported. Configuration is stored in /option/~/vendor.Cyrusoft/Mulberry/
As mentioned, there's no NOTIFY support. Various attributes are not used, and cannot be seen or edited. Worse, Mulberry deletes entries (via a STORE to the "entry" of NIL) before recreating them with the new values on an edit, so any changes made to the entry by a different client will be lost.
Bizarrely, Mulberry insists that the addressbook.CommonName attribute of an entry describing an addressbook must, itself, be a URL relative to /addressbook/ giving the path to the entry - this information is, of course, already present in the subdataset attribute, but Mulberry appears to ginore this value. This merely means your addressbook names are ugly - annoying, but not fatal.
Final niggle - attributes which are not specified by the user, but that Mulberry understands, are set to the empty string. This is annoying, as it means working around that in every other client - they should be left unaltered.
Of course, you can prevent Mulberry seeing your addressbooks from other clients just by naming them in such a way that Mulberry can't access them, but that's a little draconian.
Aside from those pains, the support works reasonably well. Recent fixes to Mulberry mean that many of the bugs in release versions have vanished.
Setting it up is easy - just switch to advanced preferences, select the Accounts tab, and add a new "ACAP Addressbook" account. You'll need to formally look at your addressbooks before trying to set one of the ACAP ones as a Capture mailbox, though.
Adding shared addressbooks means entering the entire ACAP dataset path, which may fox the unwary. Typically, this'll be something like /addressbook/group/shared/ or similar.
To set this up, switch to advanced preferences, select the Accounts tab, and add a new "ACAP options" account. You'll need to tell Mulberry to use these on startup, rather than the local settings, in the options. Further, you'll need to hit the "Remote" radio box on the right hand side.
Typically, you'll only have one entry present in Mulberry's configuration dataset, which will contain a huge amount of attributes. Unfortunately, this does slow Infotrope down considerably, since the ACL lookups aren't as susceptible to caching. Worse, Infotrope drops the cache after a STORE to that dataset - which happens every time you open Preferences.
You can save alternate sets of preferences, too.
Unlike the addressbook support, the ACAP connection is opened and dropped with every load or store, which might mean a slowdown while editing preferences stored on a remote server. On the other hand, how often do you edit preferences anyway?
I have literally no idea what effect inheritance might have on entries within this dataset. It seems likely that it'll "just work".
Mulberry's support for ACAP is pretty basic - it's really treating it much like IMSP, whereas ACAP is capable of providing a lot more support. That said, it's providing support for addressbooks, and that's a useful area of interoperability right there. In addition, it should work pretty well with Roaming - I haven't tried it, since I've only the one Windows machine I run Mulberry on, but it should "just work".
Certainly I can wipe the local configuration from the registry on Windows, start Mulberry, switch to advanced preferences, insert the relevant details for the ACAP options account, and open the remote preference set, and it seems to use it. Oddly, it also seems to remember the password, although that might purely be because I've had to type it in in order for it to get at the preferences. If it's storing the passwords in ACAP, you probably want to use ACLs quite heavily, and consider whether you really want to use it at all - bear in mind that Mulberry doesn't, as far as I'm aware, support TLS or SASL-based encryption in the basic version, you need the crypto version for that.
You'll also need to switch to Local preferences, and save - just to get the preferences about which options account to use saved somewhere locally - Mulberry doesn't appear to try and synchronise local preference information at all.