Strictly speaking you're probably correct. But the problem is that OP is giving as an example a team, without strictly defining the expected behaviour of that class, so everyone starts to imagine his own set of behaviour ovverides, invariants, and so on, and in many cases they are right (the salient point of subclassing is method overriding).
The problem really starts when an invariant supported by a superclass is broken by it subclass. For instance, the idea that a player is unique in a team is obvious, so as said elsewhere in this thread, the Add method, whose invariant is to increment by one the size of the list (because duplicates are allowed, and pretty much no predicate other than equality is applicable to a generic type), would be broken by that Team subclass, and thus any function relying on that implicit behaviour (afaik, c# doesn't implement contracts) would break.
That Liksov substituton principle is tough indeed.
The problem really starts when an invariant supported by a superclass is broken by it subclass. For instance, the idea that a player is unique in a team is obvious, so as said elsewhere in this thread, the Add method, whose invariant is to increment by one the size of the list (because duplicates are allowed, and pretty much no predicate other than equality is applicable to a generic type), would be broken by that Team subclass, and thus any function relying on that implicit behaviour (afaik, c# doesn't implement contracts) would break.
That Liksov substituton principle is tough indeed.