Quite often it makes sense to design a board so that it can accept a part in one of several alternative packages - let's say two: one in SOIC and the other TSOP. The footprints differ from one package to the other so there are two land patterns. In some cases the land patterns may share one or more pads, but only one pattern at a time is ever fully used - the remaining pads have nothing soldered to them.
Different CAD packages variously allow or force different ways of achieving this. One method, popular in Eagle, involves creating two separate devices. Each has its own package and most likely their symbols are identical (except for values that designate the style of package). Both symbols appear in the schematic and are connected pin-for-pin (typically with a "Fit Only One"or similar annotation). This achieves what we want as a (desired) side-effect: it puts the land patterns for both packages on the board, and routes tracks which connect their matching pins.
But is it really a side-effect: does describing it as such denigrate it unfairly; or is it being overly generous by making a virtue of necessity? In Eagle's case there are few or no practical alternatives to that approach, yet there are reasonable arguments both for and against it.
- The board-centric argument says the schematic should represent the PCB: the board can accommodate either package, so the schematic should reflect that by showing two symbols.
- The schematic-centric argument says the opposite: the schematic should show only what happens electrically, so two symbols shouldn't appear on the schematic just because there's a choice on the board - only one is ever present.
The issue goes to the heart of what a schematic actually is: is it a purely electrical diagram; or should it reflect aspects of the physical implementation and if so to what extent? That may seem too abstract to bother about, but CAD vendors make programming decisions based on how they answer it. Those decisions affect how Eagle works and in turn how we can or have to work with it.
More important, once a tool is established it can be hard to add certain enhancements if its programming model is based on one view or the other. Therefore I'm posting this partly out of interest - it's a perennial debate among engineers - but mainly in the hope of stimulating discussion which may influence future versions of Eagle.