It's intentional behavior as far as I know, so no bug. That being said, if Swift were redesigned from scratch, maybe we'd choose a different behavior with different tradeoffs. I don't think there's an obviously better solution to fix this.
At the time, @dabrahams had the idea that classes should not be allowed to conform to protocols with mutating requirements. At the very least, he brought up the problem and hoped we could think more on it. And this is Dave, who tolerates the existence of classes at best. ;-) But that doesn’t solve the extension method part, and, well, really this is about reference semantics, not classes specifically. (Consider using isSorted with UnsafeMutableBufferPointer.)
Yeah, it certainly won’t be “fixed”; in the worst case the rules would become stricter somehow in a new major version. (I have used this trick myself, though I’d prefer proper factory init support.) See also SR-142.
That said, I usually wouldn’t bother to force singleton-hood like this. I’d just make a lazy static property called shared.