Summary of my conversation with Yusra and Jim:
We should treat VisitSummary as a code interface, not a data product, because it is a temporary internal product. We do have an explicit guarantee that you can read data produced with older code with new code; we do not have a guarantee that you can process old data with new code (for example, running difference imaging with old coadds, or postprocess/analysis_tools on old calexps/tables).
In the context of this ticket, this means that developers can add fields to VisitSummary and assume in downstream code-released concurrently with or after the addition-that those fields will exist, while the removal of fields from VisitSummary or significant changes to meanings requires an RFC and potentially a deprecation period. This also means that VisitSummary is explicitly not versioned: its effective version is tied directly to the version of Science Pipelines that was used to produce it and use it.
I don't know if the above is fully captured in RFC-699: that RFC mostly discusses reading of old data, but I had interpreted some of it to refer to further processing of older intermediate data products.