Right, that's similar to the radio example I gave (multiple vendors so that there was no single point of failure, it mitigated risk and, in theory, reduces cost by introducing competition). What I meant by aircraft though was that for a specific aircraft, it'll be run by a specific contractor for all or nearly all its subcomponents. Though there could be exceptions. See the way that heavies (cargo, AWACS, and the like) are given multiple missions and some of the mission specific components may be separate programs rather than executed by the prime for the aircraft. But you won't have the government contract for the engine and the airframe separately.

Though you also have that done for aircraft. The F-35 was selected among several aircraft that were being developed by various contractors as the one to move forward as the JSF. This is where the lifecycle of a program comes into play. In the R&D stages you'll see multiple options quite commonly because they want to compete different vendors. Eventually it whittles down to one for things like aircraft to move forward. Though, using the JSF as an example, maybe they should select multiple. LM were the geniuses that thought you could increase software productivity by hiring more programmers and having them work in shifts.