Not all services will need FEC, some are more fault tolerant than others. I would say that FEC at the lowest level should be optional - at best, and than it could certainly be incorporated at a higher level for applications least tolerant to packet loss. Fixed-to-fixed services are much less likely to benefit from FEC, while I can see that mobile apps may benefit from it.
At these speeds, interference is likely to impact more that the occasional single bit, which is why FEC overhead may not be worth the trouble.
I can say that from previous experience at 56 kbps on 70 cm (both fixed and mobile), packet loss was very low, and giving up even 10% to FEC would have been wasteful - for typical terminal sessions. Encoding voice in a more resilient way, including either FEC or other tricks (silence/replication for lost segments) could provide a better experience.
But I wouldn't make FEC at the packet level a mandatory requirement until shown to be necessary after real world testing. Leaving it to the higher levels would also mean that the most appropriate form of FEC could be tailored to each application.
High speed/high tolerance for error (e.g., compressed video?) may suffer more from FEC than would be gained, where slower speed/low tolerance for error applications would cause little extra channel overhead while using FEC. Each application could get the FEC that it needs (or doesn't need).
From the earlier desciption, that's basically the D-Star approach.
- Richard, VE7CVS