Stripping WCS cards is orthogonal to stripping general headers like INSTRUME and EXPTIME. We absolutely should be stripping all the WCS cards if we are going to write an updated WCS to the file. In
RFC-576 we agreed that we would put all input headers in the output files (for coadds dropping any that differ) and I'd rather we didn't reopen that discussion. Robert Lupton I assume you are solely objecting to the case where VisitInfo has a value and not the headers that VisitInfo has not interest in?
I understand that there is a tension between propagating instrument headers to the output files and using LSST standardized headers in the output files. If instrument headers appear then all the observatory tooling that knows about raw data headers can still work on processed headers. Conversely, if everything is standardized in LSST headers all processed files regardless of instrument can be examined in a unified way.
Note that headers are stripped based on ObservationInfo which is a superset of VisitInfo content, so when headers are stripped as part of VisitInfo construction you have no way to reconstruct some of the information.
I would much prefer a scheme where the raw header is always propagated to the output files (dropping things that differ) and at the end of the header there is a standardized LSST block of cards detailing the LSST view of the header and any additional information calculated by processing. Yes, you end up with some information present in two places but I don't see that as a disaster. Raw headers propagated to the output will not be updated by processing and users will know that. This way we don't lose anything.
Regarding CD matrix, the only motivation I can see for adding missing CD entries is to support FITS readers that aren't following the FITS standard. If we have to do it we have to do it but I would rather the reader code conformed to the standard. I'm not going to try to block the addition of them though.