FEC is just overhead unless you really need it. On nearly loss-less channels (which is what we should expect on short haul 70 cm links), you lose more throughput than you gain with FEC. If we were talking about long haul lossy links (as on HF), then FEC can be a winner. This is a reason that D-Star does not use FEC (and no one is complaining about packet loss there), and I don't believe that we'll need it for most applicaitons either. Time will tell, and there's nothing stopping anyone from comparing FEC to non-FEC transmissions and measuring it in real life...
You ask some interesting questions about channel allocation and use - I doubt that we will settle this before the radio ships, it is something that I know that I will be experimenting with - and I know that others will be doing the same. The beauty of SDR is that the standard doesn't need to be cast in stone, and there may be reasons for more than one standard depending on the network topology (a few stations scattered along a long distance may need a different solution than a city full of adjacent stations). Even after the first standard(s) are in place, if experimentation comes up with a better scheme some time later - it's trivial to load new software and reinvent the entire network!
As to channel allocation, one suggestion is to use an ISDN-like approach, with a fixed, narrow control channel that does all (or most) of the channel assignments, and then the rest of the bandwidth can be sliced-and-diced as needed. Deciding how this is coordinated among stations that do not have complete connectivity with one another (a distributed mesh) is one of the issues that needs to be tackled - but there are some simple allocation schemes that can be used to start. I certainly don't want to see a master/slave approach, but more like 'cooperating masters', where every station is part of the control puzzle. Some heuristics can be built to map the network and determine how to best use the channels at any given time, and give appropriate QOS based on the type of traffic - e.g., audio traffic is much more sensitive to latency than email or SSH connections.
- Richard, VE7CVS