...
As an example, <Rick puts an example here>.
I'll add a comment too. I don't think there is any need for long-term editing. During a release (same semester), Admins occasionally do edits to correct some issues, but that is usually within the first week post-deadline. Edits farther out are just not done, and really are against policy.
As for copying, that is an extensively used feature and as noted causes problems in the current PST. Deprecated backends (not uncommon with the GBT) are adequately handled in the current PST, but improvements could be made. As for resource changes, copying a proposal with a substantial change between versions of an active resource is problematic. UI issues, model issues, and database issues.
A particularly good example is GMVA for 21A. GMVA (much like VLBA) has some correlation options and a list of stations. The stations were grouped by US and European. There were some UI dependencies that allowed selecting all European stations by clicking one checkbox, etc. Some stations may also be disabled in conjunction with another station selection. This has always been a mess in the PST. But for 21A, they wanted to modify some stations, regroup them (Member and Other), and change some of the dependencies. Maintenance nightmare. This also means historical proposal will be using some columns that new proposals won't use and vice versa. And if you copy proposals, how do you map the stations. Supporting UIs for both versions of the resources would add a whole new level of complexity to the UI for the benefit of ~5 proposals / semester. We went for the quick fix: discourage GMVA proposal copying.
Now for the good news. For the GMVA the correlation parameters are fixed. So you can't select different values. That was the saving grace. Had this happened on the VLBA, many of the correlation parameters are dependent on stations (e.g., 4Gbps not available at Arecibo for HSA). That would have generated an explosion in the number of dependency changes.