Use cases are typically arranged by priority, and are used to plan iterations. Therefore you would never distribute them evenly among team members. So A is wrong.
The same goes for B. Your teams should be focused on iterations which are driven by use cases. So you would not have one team implement a common code path. In fact, in a distributed system I'm not really sure what they mean by a common code path. Having other teams implement the error paths is ludicrous.
C is interesting, because
you should actually use use cases to schedule the work. Having teams organized according to package dependencies also makes sense.
While D is often what happens in a project because of the skills or interests of the developers, it is probably not as good an answer as C. Here again is the statement, "work as independently as possible in order to minimize dependencies". Well, dependencies exist no matter what.
dan'l