Please leave in a record of who wrote what.

If you need a deep copy, use a class and implement ICloneable. It's never
the default, so that's not an issue.

Not copying all the fields would run counter to the idea of a copy
constructor... Even if you wanted this for a legitimate reason, separately
copying fields would be slower than letting the framework do a single block
copy, unless the fields you want to skip are very large. In which case,
you've got a very odd struct that you probably shouldn't be "copying" in the
first place. Just create a new one explicitly and assign its fields
explicitly, so everybody knows what you're doing.

Note that a C# "copy constructor" is not at all comparable to the C++ copy
constructor. The latter is a part of the language, the former is just
another constructor (and not in any way special). In particular, assuming
'b' is of a type compatible with T, then

  T a = b;

will never invoke any constructor in C#,

  T a(b);

is a syntax error, and

  T a = new T(b);

will not compile unless you've actually written a constructor that takes an
argument that's type-compatible with T.

That sounds like a very odd usage - and selected copying is likely to
be slower than just blitting.

What makes you think it performs deep copies at the moment?