And (technically) it could be problematic there too. Imagine (intentionally exaggerated for purpose of explanation; I know such full-blows situations would be quite rare to say the least) amenity=parking + access=yes + capacity=100 + capacity:charging=100 + capacity:women=100 + capacity:disabled=100.
I would definitely call that problematic, as it’s basically saying “Here is a car parking for you, but only if you are women who is disabled and is driving an electric vehicle. Otherwise, no parking for you!”. Imagine the chaos is significant amount of car parkings were tagged as such!
The issue is that each data consumer would have to know not only to parse all those tags, but also ask all those questions about driver (sex, disability card ownership, ICE/electric car, etc.) before it could reliably show you parkings. And if the new tag appears (say capacity:h2, it would again mislead all data consumers if capacity:h2 = capacity until they were all upgraded. Such data model would not be sustainable)
Luckily, such combinations (e.g. capacity=capacity:women) are extremely rare for whole car parkings (tagged with amenity=parking), thus the issue is mostly moot there. Not so for swingsets: there are many swingsets which are baby-only. Thus, the issue becomes the real problem there.
The other crucial difference is that in the case of the parking the restrictions go only one way, while in a case of swings restrictions go both ways, which makes even regular-only swings problem (something which is never a problem for car parkings).
IOW, if there are 100 “regular” parking spaces, even women and disabled persons and electric cars owners CAN park there too. But if there are only 10 “regular” swings, babies CANNOT use them. You have to have specialized baby swings for them.
To summarize, capacity:* tags (or any other additional tags) are just fine if they only add details and can be completely ignored without changing the meaning (i.e. capacity:whatever=* value would practically never be equal to capacity=* value!)
Same is fine for swings : if the swingset has 4 baby swings and 6 regular swings, it would be fine to use capacity=10 and capacity:baby=4), as it does not change the meaning of a playground=swing if data consumer ignores all capacity* tags (as most of them do). There are after all regular swings there and they can be used as such; and if you do not know about detailed tags like capacity:baby, you’d just lose knowledge that there are additionally some baby swings there if you don’t process those extra tags.
That is crucial difference – it that particular case; you’d just provide less detail (just as if you for example forgot to map some amenity=bench that are present), but you will not mislead data consumer which do not know about your additional tags. Thus, it is OK.
But if it is somewhat regularly occurring situation that whole swingset has only baby tags (e.g. capacity=8 and capacity:baby=8 on that playground=swing) as in that example picture above, that it is hugely problematic to use only those capacity tags to distinguish – as someone not knowing about capacity:baby=* tag will be mislead that there is a regular swing, when there is not.
Using playground=swing + playground=baby_swing (with optional capacity on each) solves that problem completely, which is why I find using that preferable.
I hope I have managed to explain the rationale why that option (separating playground=swing and playground=baby_swing) has been deemed most popular by the community.
Note that I have no particular intention of telling anyone what they must do: you’re free to tag any way you like, I just thought it prudent to provide you with enough information to weight why some solutions are worse then others, and help you make an educated decision. It’s your choice in the end!
Happy mapping!