If I understand correctly (and that's a big if 
) I think the difference isn't so much with copy_addr and copy_value, but what they imply. An address-only type will never be destructured, for example, and that is not the case with a loadable type (there are several passes that might destructure loadable values for various reasons). There are places in the optimizer where a copy_value might be turned into a destructure + several copy_values and that would (hopefully) never happen to a copy_addr. This is important because the former would be OK no matter the C++ type, whereas the latter may be quite problematic if the copy constructor is non-trivial.
Any C++ types that are substitutable for generic parameters without any additional constraint must also be copyable.
I'm not sure I agree with this. I think the idea is that we're going to substitute all C++ types either before SILGen or in a raw SIL pass. See this post.
Swift code simply won't provide the same semantic guarantee on value lifetimes as C++. The Swift compiler won't guarantee the order of copy constructors (or destructors), or the number of copies performed. Hopefully I'm just restating what you're saying above--Swift will not have special-case semantics for C++ types.
For what it's worth, I agree that this is both OK and important.
From my point of view, a C++ type with global copy side effects should not be generically subtitutable without an additional type constraint. But I realize that may not be the programming model you're shooting for.
But it would be OK if it were a concrete type (i.e., not a generic substitution)? Does the above proposal for generics solve this?