Why do some WiFi routers block multicast packets going from wired to wireless?

I have worked with dozens of consumer grade WiFi routers, and they have been really hit-or-miss with this, though it seems to be getting better.

Example of issue:

1. A device that can be discovered with mDNS is connected into the router with a cable.
2. Another device connected to the router on WiFi attempts to discover the device in step 1.
3. Packets from the device on WiFi don't make it to the wired device, or if they do, packets sent from the wired device don't make it to the wireless device.

Many routers have settings allowing this to work.

See http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073 and http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired-and-wireless-network-on-actiontec/td-p/461359 for examples.

Is there a list anywhere of incompatibility with this? What is the cause? Just a bug in the router?

It's usually due to bugs in the Wi-Fi home gateway routers (APs), or sometimes in the wireless client chipsets/drivers/software.

On Wi-Fi, sending multicasts from the AP to the wireless clients (this is known in the standard as "From the Distribution System" or "FromDS") is tricky, so there are lots of ways it can fail, and it's easy to introduce bugs.

1. Even though the radio medium is unreliable enough that 802.11 unicasts are required to have link-level acknowledgements (ACKs) and get retransmitted several times if there's no ACK, FromDS multicasts are never ACKed because they'd need to be ACKed by all the wireless clients of the AP, which could be quite an "ACK storm". So instead, FromDS multicasts have to be sent at a low data rate; using a simpler, slower, easy-to-decode-even-at-low-signal-to-noise-ratios modulation scheme, that can hopefully be received reliably by all the clients of the AP. Some APs let the administrator set the multicast rate, and some administrators unwittingly set it too high for some of their clients to receive reliably, breaking multicast delivery to those clients.
2. When WPA (TKIP) or WPA2 (AES-CCMP) encryption is in use, FromDS multicasts have to be encrypted with a separate encryption key that is known to all of the clients (this is called the Group Key).
3. When a client leaves the network, or every hour or so, just for good measure, the Group Key needs to be changed so that the client that left no longer has access to decrypt the multicasts. This "Group Key Rotation" process sometimes has problems. If a client doesn't acknowledge receipt of the new group key, the AP is supposed to de-authenticate that client, but if it fails to do that due to a bug, a client could have the wrong group key and thus be "deaf" to multicasts without realizing it.
4. When WPA2 "mixed mode" is enabled (that is, when both WPA and WPA2 are enabled at the same time), the FromDS multicasts typically have to be encoded with the TKIP cipher, so that all clients are guaranteed to know how to decode it.
5. FromDS multicasts have to be queued up by the AP and only transmitted at times when all clients who care about multicasts can be expected to have their receivers powered on. The time between the "safe to transmit FromDS multicasts" periods is called the "DTIM interval". If the AP or clients screw up their DTIM interval handling, it could result in clients unable to receive multicasts reliably.
6. Some APs have features to keep wireless clients from being able to talk directly to each other, to maybe keep your wireless guests from hacking your other wireless guests. These features usually block multicasts from WLAN devices to other WLAN devices, and could well be implemented in a naive way that even blocks multicasts from LAN to WLAN.

The crazy thing is, "ToDS" multicasts are done just like ToDS unicasts, and so they rarely break. And since ToDS multicasts (not FromDS multicasts) are all that are needed when a wireless client gets a DHCP lease and ARPs to find its default gateway, most clients are able to get connected and surf the web, check email, etc. even when FromDS multicasts are broken. So a lot of people don't realize they have multicast problems on their network until they try to do things like mDNS (a.k.a. IETF ZeroConf, Apple Bonjour, Avahi, etc.).

A couple other things to note, regarding wired to wireless multicast transmissions:

1. Most LAN multicasts, such as mDNS, are done using special multicast address ranges that are not meant to be routed across routers. Since Wi-Fi-capable home gateways with NAT enabled count as routers, mDNS is not meant to cross from WAN to [W]LAN. But it SHOULD work from LAN to WLAN.
2. Because multicasts on Wi-Fi have to be sent at a low data rate, they take up a lot of airtime. So they're "expensive", and you don't want to have too many of them. That's the opposite of how things work on wired Ethernet, where multicasts are "less expensive" than sending separate unicasts to each machine "tuning into a multicast video stream" for example. Because of this, many Wi-Fi APs will do "IGMP Snooping" to watch which machines are sending Internet Group Management Protocol (IGMP) requests, expressing their desire to tune into a given multicast stream. Wi-Fi APs that do IGMP Snooping won't automatically forward some classes of multicasts onto the wireless network unless they see a wireless client try to subscribe to that stream via IGMP. The documents that describe how to do IGMP Snooping properly make it clear that certain classes of low-bandwidth multicasts (mDNS fits in this category) are supposed to always be forwarded even if no one has explicitly asked for them via IGMP. However, I wouldn't be surprised if there are broken IGMP Snooping implementations out there that absolutely never forward any kind of multicast until it sees an IGMP request for it.

tl;dr: Bugs. Lots of opportunities for bugs. And occasional poorly-designed features and configuration errors. Your best defense is to buy high-quality APs from companies that care about making sure multicasts work. Since Apple loves Bonjour (mDNS) so much, Apple's APs are probably the most consistently excellent at passing multicasts reliably, and Apple's Wi-Fi client devices are probably the most consistently excellent at receiving multicasts reliably.

@Spiff made some awesome points in his answer and I won't reiterate here. But there are some other answers and alternatives to get around this issue.

Short answer? I don;t think they always "block" so much as they just "don't do it ot begin with" due to engineer laziness creating any particular device. Some don't have it as a high priority, and some just don't have the time to make it work.

It's not high on the priority list compared to all the new "features" marketing is using to sell these consumer grade devices and it's a feature most non-tech savvy people have no clue about, so down the priority list it goes until the point that unless a large pool of owners complain about it, it gets left out of any revision updates.

If you want a device that supports it, do the due diligence on your research and you'll get a device that supports it, or if you can find a new or used device that supports something like OpenWrt or Tomato from Polarcloud, you can be assured of getting what you need.

Good luck. :)