This is due to how merged patches are detected : any conflict trying to unapply the patch causes the merge not to be noticed, and leaves the user with a useless conflict to solve.

One way to handle this is to automate the manual process I use, described here fo a single patch:

1. first, one must note that this notion only makes sense after pulling, and we are looking for patches being merged between a former stack base and the current one. The current revision of the patch being push--merged may be sometimes used to find the old base, but a rewinding-head parent makes it harder: maybe we need to track the current base as a patch attribute ?

2. try to push the patch as we currently do (maybe even use the current merge-detection code)

3. if that fails, identify the latest conflicting patch. If below the fomer base, then we have a real conflict; else temporarily rebase to the parent of this conflicting patch, and recurse, until we find it merged or until we're sure we conflict.

4. rebase back if needed, and push with conflict if needed

When we need to "push --merge" a full stack, I fear the only safe way is just to repeat these operations for all patches.