How many message sets should one IEPD cover:
1) A single message, a portion of a set;
2) A single message set, a single exchange from start to end;
3) Many message sets?
What is the impact of placing to many or to few message sets in an IEPD?

There is no guidance at this point as to how many exchanges an IEPD should cover.  
In fact, PMO is in the process of refining an IEPD specification, so some of this may be subject to change in the future.

That said, the concept of an IEPD is meant to be simple and scalable.  If I create an IEPD for a set of related exchanges (or message payloads) like a set of queries and associated responses, and they all use the same subset and extension schemas, then it's probably a good idea to put them all into a single IEPD with a name that embodies the business purpose or function of these queries/responses.  If I have a fairly large exchange (such as a Rap Sheet or a SAR) then it's probably better to keep that by itself in a single IEPD.  If some kind of small query goes with that exchange (to trigger it or request it), then it's probably a good idea to keep that in that IEPD as well.  The user must decide how cohesive a set of exchanges are.  The more cohesive a set of exchanges are (either from a business perspective, functional perspective, or possibly organizational perspective, the more likely they should be together in one IEPD, especially if they employ/share the same subset and extension schemas.

The impact of too many or too few?  As far as we know, there is no answer to this question.  Again, the IEPD concept is meant to be simple.  Does it simplify usability and understanding to combine exchanges into a single IEPD with one set of documentation?  Are the exchanges fairly cohesive and depend on the same subset and extension schemas?  Will creating a single large IEPD (with many exchanges) be more confusing or less confusing than making each a separate IEPD (possibly with lineage)?  These are the kinds of questions a developer must answer to determine the best approach.