That all depends on the TPs and your software. It depends on whether you're the buyer or the seller. We are buyers, so my boss took the tack that we are the ones paying so we shouldn't jump through hoops to meet their needs. It has worked; we've got EDI up for all our big $ vendors (nearly 20). Any vendor that did enough business with us but balked at using our version, we left the fight to Purchasing and AP to apply a little pressure; in most cases it worked. There are a lot of vendors we don't do EDI with, but we don't purchase much from them anyway. You'll find that many vendors have no provision for testing at all and are can be inflexible about changing their map to meet our needs. We've tried to be accomodating in small ways but draw the line at the big stuff like version#.
We settled on 1 version of EDI back when, however, we have one TP that insisted the 820's we sent to them had to be an older version and we only did that for our distributor. Many TPs We've tried to consolidate our transactions into as few maps as possible and, for the most part, it has worked. We've done it in line with where the actual file comes in - we have one mailbox set up with a van (secure telnet) and we have another mailbox set up with files that are ftp'd to our server directly. Because they're requirements are so different, it made sense to do a different map. So we have 2 basic sets for the 2 mailboxes and a few other maps for the exceptions.
What we found is that we will set up a transaction map to meet needs of one or more TP which works fine, but then another TP comes up and you'll have to tweak the map to incorporate them. Eventually your map will be flexible and comprehensive enough tweaking is unnecessary. So, piece of advice - plan early that your map will need changing and build it so it's easy to do. It may avoid headaches and major re-working down the road.