Q:

What, exactly, is required to make Airplay work across VLANs?

It seems like AirPlay works out-of-the-box, vaguely speaking, only within a LAN.  It's not clear to me exactly why, but it looks like at least discovery relies on broadcasts.  Wikipedia states that Airplay is a proprietary protocol which probably explains why the only documentation I've found is unofficial like this spec at github.
So, my questions are:

Can a network be configured such that Airplay works across VLANs?
If so, what, exactly, must be allowed to pass between the VLANs to make this work?
Is this a bad idea in a production environment given the unavailability of official protocol documentation?

A:

There is two different things in term "Airplay".
The first one is about service discovery and it's the way how devices capable of receiving Airplay streams announce to the network "Hey! I can receive Airplay!". It's done normally via service called Bonjour (at least Apple calls it so) or DNS-SD. It's using multicast and that's the point if someone is telling to you that "Airplay is for local LAN only" or something. The streaming itself is "normal" UDP unicast.
Now the main problem is how you get the info about Airplay receiver to the potential senders in another network. There is two theoretical options:

You can forward multicast. It might be tricky though, but there are routers/firewalls capable of this. RTFM how exactly, but the idea is that you have to forward multicast traffic with destination address 224.0.0.251 to another network and you have to do it without decrementing TTL.
Another option is to use unicast DNS-SD. You can use normal DNS to announce the very same info normally distributed automatically via multicast DNS-SD and you can use a little help from dns-sd(1) utility on your MacOSX to get an info what exactly to write into your DNS zone file. Execute this command in the LAN with Airplay receiver and this should give to you all the info you need:
$ dns-sd -Z _airplay._tcp
Browsing for _airplay._tcp
...

There is also DNS-SD proxies (for example avahi can be used as such).

Now, I said "theoretically", because I haven't tested it and whatever you do with protocols, forwarding and so on, there MIGHT be some roadblocks beyond your control - it's the Apple after all. You could get all info correctly to the potential sender, but iOS/MacOSX might still reject it because it just doesn't like it for some reason and so on.
There is one more (again theoretical though ;) brute force option - create a DNS-SD entry for your router address as an Airplay receiver for the network with Airplay senders and forward (NAT) the UDP stream to the real Airplay receiver. But even with this there are some possibilities (for Apple engineers) to break it.
Go on, test it and let us know about your results.

A:

This is a common problem in educational environments.  Apple has done an excellent job of selling iPads and Macs to students/staff and they want to utilize Airplay/Airprint/other Bonjour functionality.  However, as you pointed out, these features rely upon a single broadcast domain for service discovery.  Enterprise/educational networks just aren't structured that way.
The problem is so prevalent that many educational institution IT staff got together a few years ago, and petitioned Apple to fix Bonjour to work better in these environments.

To directly address your questions, it will usually require very specialized configurations to accomplish the spanning of Airplay services across your network.  And the specific configuraition will depend heavily on your current wireless solution (Cisco, Aerohive, Ubiquity, etc).  In general, if you search for your wireless vendor and Bonjour, you should find documentation to at least point you in the right direction.
I have had mixed success deploying Cisco's Avahi Bonjour gateway solution, and wouldn't recommend looking into it unless you absolutely have to.
The bottom line to me is, as you pointed out in your third question, you'll always be at Apple's mercy because this is a closed, proprietary, undocumented service* intended for home network environments.  So, unless Apple decides to change that, I would avoid implementing it in an Enterprise network wherever possible.
*The underlying code for mDNSResponder is open, non-proprietary, and available under the Apache license.  However, Apple's implementations of this internal to their iDevices and MacOS are all outside your control and could change at anytime.

A:

Avahi can help you here. There are lots of options but this should get the traffic across the subnets. You should be able to get it on a ddwrt box or use a Raspberry Pi and dot1q interfaces.       
 enable-reflector= Takes a boolean value ("yes"  or  "no").  If  set  to
       "yes"  avahi-daemon  will  reflect  incoming mDNS requests to all local
       network interfaces, effectively allowing clients to browse  mDNS/DNS-SD
       services  on  all  networks  connected  to  the gateway. The gateway is
       somewhat intelligent and should work with all kinds  of  mDNS  traffic,
       though  some functionality is lost (specifically the unicast reply bit,
       which is used rarely anyway). Make sure to not run multiple  reflectors
       between the same networks, this might cause them to play Ping Pong with
       mDNS packets. Defaults to "no".

 reflect-ipv= Takes a boolean value ("yes" or "no"). If set to "yes" and
       enable-reflector  is  enabled,  avahi-daemon  will forward mDNS traffic
       between IPv4 and IPv6, which is usually not  recommended.  Defaults  to
       "no".

