OK, here's how to do it. First, the two radios want the length byte in different places for their packet handlers to accept them. You might be able to find a way to finesse that by putting the length byte where your receiver wants it, but you'll sacrifice other radios of the sender's type receiving those packets. E.g., the RF69 wants the length in the first byte. The RF23 wants it after the headers. You can send a packet from a 69 with the length byte cobbled in after your headers, but all receiving 69s will reject it as a bad packet.
One good solution to that is to change to fixed-length packets, in which case the two radios won't expect a length byte, and both agree that the packet shape is <headers><data><CRC> - if you enable the CRC.
Next, the CRC. Turns out the 69s use CCITT, but it's the 1D0F version of CCITT (there are at least four versions of the same CRC algorithm, with different results!). You can set the 23s to use CCITT (one of four CRC algorithms they'll accept), but that wants the Xmodem implementation of CCITT. Half conveniently, there's an AVR-libc function for xmodem CRC, but not for the 1D0F version. Lots of code out there though. I got this to work with the CRC calculated on the data only on both sides, though you might be able to get it working for the CRC calculated on the headers too, don't know yet. But, you'll always need the transmit CRC turned off if sending to a different radio, and turned on to send to a same radio.
As noted in one of the posts above, you'll want a radio modem setting that works for both, and I'd recommend starting with GFSK_Rb2Fd5, which works very well.
Finally, the packet length is a set of hoops too. I found that you want to turn off the rx_multi_packet on the 23 (I think it's off by default) - the diagram in their datasheet suggests that it needs to be on for fixed packets, but it's just misleading. Next, your packet length on the 69 (for sending to the 23) is the headers + data + CRC. For receiving that on the 23, it's the headers + data. Since you have to fill in the CRC, you're telling your transmitting side that the packet is two bytes bigger, to hold the CRC. On the receiver side, the packet handler will strip that two bytes off after validating the CRC, so you don't count them in the receive side.
One more thing that helped me a lot. With multi packet receive turned off on the 23, set your fifo warning length to the size of your packet. (RH_RF22_RXFFAFULL_THRESHOLD on the 23.) Not sure if this is needed, but that's part of the last set of changes that worked for me.
Finally, ask yourself if you really want to develop for the 23. It's old, you probably don't need the extra power output (69s have much lower transmit power, but *much* more sensitive receivers, so they're actually better), and all of this is a pain compared to just sticking with 69 or newer modules. Also, Oshpark has lots of boards that convert 5v signals from your MCU to the 3.3v RFM69 pins, so there are fairly easy ways to use a 69 with 5v boards. I kind of wish I'd gone that route, having wasted a good deal of time ironing out the remaining problems.
