Seems to be working for me on VxWorks 6.9, I can connect to PVs, and outgoing CA client connections still work OK too (although I didn't test setting CA_ADDR_LIST).

Also works with a second network interface configured at 10.0.0.2 (but not actually connected to anything):

iocanj> casr 2
Channel Access Server V4.13
No clients connected.
Server interface 0.0.0.0:5064
 UDP receiver 1 0.0.0.0:5064
Beacon destination 10.0.0.255:5065
Beacon destination 164.54.11.255:5065
There are currently 1288 bytes on the server's free list
7 client(s), 0 channel(s), 0 event(s) (monitors) 0 putNotify(s)
0 small buffers (16384 bytes ea), and 0 jumbo buffers (16408 bytes ea)
The server's resource id conversion table:
Bucket entries in use = 0 bytes in use = 16404
Bucket entries/hash id - mean = 0.000000 std dev = 0.000000 max = 0
The server's array size limit is 16408 bytes max
Channel Access Address List
10.0.0.255:5065
164.54.11.255:5065
value = 19 = 0x13

The "Server interface 0.0.0.0:5064" and "UDP receiver 1 0.0.0.0:5064" lines are slightly confusing in the above status message, although I guess they do make sense. At least the casr command now shows the dynamically allocated TCP port number (which used to only show up at iocInit, making it hard to look up later on).

when running on an IOC without DNS properly configured the two entries in the CA Address list at the bottom take a minute or two each to print while waiting for the DNS search to time out; in my experience network administrators don't add names for their broadcast IP addresses to DNS, so why are we querying DNS before printing just the numbers in that list? I guess there might be host IPs in there too, but in this case I would be happy with just printing the numbers even for them. You probably haven't touched this part of the code though...

Pointing EPICS_CAS_INTF_ADDR_LIST to my secondary interface's IP address stopped CA searches from the primary network being seen/replied to.

When I pointed EPICS_CAS_INTF_ADDR_LIST to my primary interface's broadcast address though, the error message was not quite as helpful as it could be:

Starting iocInit
############################################################################
## EPICS R3.15.3-DEV $$Date: Sun 2015-11-22 18:10:40 +0100 $$
## EPICS Base built Jan 20 2016
############################################################################
Warning: RSRV has empty beacon address list
CAS: Socket bind 164.54.11.255:5064 error was "S_errno_EINVAL"
Thread tShell0 (0x6f6c70) can't proceed, suspending.

Users are going to try putting broadcast addresses in EPICS_CAS_INTF_ADDR_LIST (since they're used to using them on the client side), so if we aren't going to recognize and fix that setting automatically, there should be some kind of diagnostic explaining what the problem is in a bit more detail than is shown above. Calling cantProceeed() in that case is probably correct though.

How might I go about testing the multi-cast support?

This branch at least needs an entry in the Release Notes explaining what's new and how to configure the new features. I'm not sure if there's a suitable place in the AppDevGuide for more detail or not, although I think we did add stuff about supporting the EPICS_CAS_INTF_ADDR_LIST variable before so you might need to remove the wording about "one interface only" that I probably added.