Agreed; but this is a known issue. In one of the August dev steams, Paul mentioned that we're seeing an incomplete transition (metamorphosis?) from the original concept of shipyard-as-starbase. Hence, they must share a base class 
for their common attributes:
- hit points
- position
- renaming UI
- sensors
- can dock fleets
- display-ability in the Starbases list
They just don't (yet) override their Starbases list display differently. Maybe also the Starbases list itself is too rigid, and can't easily do two different kinds of display. Even Paul admitted that hit points isn't the most useful info to show for a starport/shipyard. So it's changing for sure.
Doodling, we have something like:
- FleetContainer has { name; xy; sensors = 4 }
- BaseBase : is-a FleetContainer; has { hp = 80; attack = 0; defense = 3 } (N.B. Planet also inherits FleetContainer, but does not have hp)
- Shipyard : is-a BaseBase, IsMovable, HasQueue; has { sponsors }
- Starbase: is-a BaseBase, HasZoc; has { constructors; modules }
- ListStarbases : is-a Tab; lambda(BaseBase b ) { this << b } (which shows b's default stats: "b.attack b.defense b.hp")
So ... we want something like a virtual display function, which Shipyard would override to HasQueue :: display, while Starbase would not (so it defaults to BaseBase :: display). Maybe also make the Starbases tab heterogeneous (if tabs weren't already).
