Thank you for expanding on Xiaodi's answer! Your example made the solution he was suggesting crystal clear. I think I adequately understand the motivation for that answer as well.
I hope I'm conveying that as a coder, it is quite unexpected to not be able to take control of a type that I am defining (or at least doing my best at defining, given that I'm just binding a generic to a type), and get it to conform to a protocol in a way that I want/need, without all these unintended consequences. I would happily do whatever is needed to avoid those consequences, but the language isn't giving me the tools to do so. It feels strange that if I want a List bound to a particular type, I can't get that list to conform to a protocol without that having repercussions on every other user of the List generic.
I do see the danger and why the policy has been defined the way it has. In fact, the whole extension mechanism, while incredibly powerful and useful, has been making me nervous. I see sample code on the net that adds extensions to List, and well, it gives me butterflies. I'm reminded of some of the creative stuff I see in the javascript world (though it's clearly not the same). I'm sure these issues have been thoroughly considered by many people, so I trust it's going to be mostly OK. 
But getting back to the matter at hand, despite seeing the sense in current policies, I also see the need for doing the sort of thing I've described and I see why it feels like such an "ought to be able to" feature.
Yes, retroactive conformances are probably not a great idea. I hope it's clear, though, that that's not the intention of the coder in the situations I'm describing, but rather they are the consequence of the coders expressing their intentions in the way the language features are directing them.
I don't at all know what's going on under the hood with generics, but I guess what I'd be looking for, as a coder, would be a way to silo off a particular Wrapper<Int> that would be distinct from someone else's Wrapper<Int> and could therefore have its own table of extensions and protocol conformance, etc. typealias is the closest to this I know in Swift right now, but it don't think it differentiates mine from someone else's in the desired way. I'm guessing it's just syntactic sugar.
However, I guess I'm not done with my thrashing, as I've thought of two potential solutions that allow me to get the results I'm seeking, at least in the example situation. Both rely on taking control of a copy of the generic by making an empty subclass, thus getting, I'm guessing, a distinct virtual table or whatever swift uses to keep track of the protocols for the type.
Aside: The original Wrapper<Int> vs Wrapper<Float> example is quite contrived, of course, and just used to illustrate how the bound generics are affecting other bindings. So for Solution 1 below, I've simplified it to only show a single binding. For Solution 2, I've used Xiaodi's suggestion.
Solution 1: Make a new class based on the bound generic, then add protocol conformance to that new class.
public class FloatWrapper : Wrapper<Float> {}
extension FloatWrapper : CustomStringConvertible {
public var description: String {
return "Wrapped version of Float with value \(self.core)"
}
}
Solution 2: Subclass the unbound generic, then add protocol conformance to that new generic.
public class SiloedWrapper <CoreType> : Wrapper <CoreType> {}
extension SiloedWrapper : CustomStringConvertible {
public var description: String {
return "Wrapped version of \(CoreType.self) with value \(self.core)"
}
}
These solutions avoid retroactive conformance on the original Wrapper generic, but they only work for non-final classes that don't already conform to the protocols in question. It would be great if there was something like typealias that did something like the above and fixed whatever problems might arise in my proposals (including working on types other than class) and relaxed some protections as allowed by the new context. For example, maybe the new type could override some extensions/protocols from the superclass, since it's clearly mine now.
Finally, I'll share a worry that's giving me some doubts about my proposals: what happens when you need to use an object of these siloed types in a context that expects one of the original type. How does type-casting work? Maybe these solutions won't work for many situations.
