If you aren't lucky enough to have them be of the base class you have to create an empty template superclass just to satisfy the compiler. Objective-c has a better solution and things can dovetail without being in the same class.
"Doing it wrong" implies that Swift is just inherently better without making a real argument about why that would be the case. And the OP is actually making a pretty convincing argument that it isn't.
Swift is awesome at doing things better than obj-c and it really does reduce a lot of template code. But maybe not in this particular instance (right now).
It's clear from what they wrote that both the parent and the author of TFA know all that you described. The problem is not that they don't know these things or that they're "doing it wrong", it's that they disagree that the way Swift does is it's the better way, or in PL terms, the most expressive way.
>Let's say he gets what he wants - a distinct collection of instances that fulfill the 'Account' contract, but are different types. The approach so far is that to fulfill 'Account' by providing an accountID. That accountID is what indicates if two 'Account's are equal. What if a Twitter account and Hacker News account have the same id? According to this protocol, they are equal.
So? There's nothing wrong with that. If that's how he defines equality and not at the class level, that's what he should get. He should still be able to use a set with his definition of "equal" (which he could trivially change anyway).