> If the post-build deliver is really a replace,
then the target stream cannot be the same stream from which the build
workspace accepts changes.

Since the snapshot is taken at the time of the accept at the start of the build, there would be little benefit in pushing it back to the same stream. The target stream already has the changes. It could only lose changes. What are you really trying to do in this scenario? Is this the "run a personal build then deliver if OK" scenario? If so, we'd also need enhance it to support personal builds.

The main issue with a regular deliver is the handling of discards and conflicts.
In the work item Geoff filed he suggests simply failing the post-build deliver if there are conflicts. That doesn't seem unreasonable to me.

But what about discards? Say a developer "delivers a discard" after the start of the build, i.e. discards one or more change sets from his workspace, then does a component replace on the target stream. How should this be handled in the post-build deliver? Like a regular developer workspace, the build workspace will see this as an outgoing change, so a regular deliver would put the changes back in the stream.

It may be possible to take advantage of the snapshot taken at the start of the build in this case, e.g. to say "at the start of the build, these changes were in the stream, and now are not, so treat it as a discard and don't put them back", but that only works if the target stream is the same as the source stream.

For the personal build case, we'd also need to allow personal builds to create a snapshot (item 193979).

Ok, let's follow up in the work item. I would like to find a better way of dealing with deletions, and it would help to understand more about your scenario for that, so if you can provide more details in the work item that would help.