The following comment was added in r38927:

/* Issue #3281.
 *
 * Skip schedule-delete children inside of schedule-replace
 * directories. They cause an out-of-date error upon commit,
 * and prevent replaced directories from being committed.
 *
 * The out-of-date error happens because we recursively delete the
 * replaced directory in the transaction, then copy the replacing
 * directory in its place, and then try to delete nodes inside
 * the directory which existed only in its pre-replaced state.
 * The attempt to delete non-existent nodes from the transaction
 * (with node kind "none") is prevented by libsvn_repos/commit.c:
 * delete_entry() which sends the out-of-date error.
 *
 * ### We should not skip deletions which happened post-replace.
 * ###
 * ### This is not possible in wc-1 right now, because post-replace
 * ### deletions are not represented in working copy meta data.
 * ### Such nodes simply have NO entry at all in wc-1. The entry
 * ### gets blown away as part of deleting the apparently "locally
 * ### added" node, instead of changing the entry's schedule to
 * ### "delete". Note that replaced directories can only happen as
 * ### part of a set of local changes, either made manually or by a
 * ### merge. That's why nodes inside of replaced dirs are always
 * ### considered "locally added". The subtleties of the
 * ### locally-added-inside-of-a-replaced-parent-directory case are
 * ### wrongfully ignored during entry deletion.
 * ###
 * ### On top of that, libsvn_repos/commit.c:add_directory() will
 * ### always do server-side copies for directories added with
 * ### history, instead of copying the directory state verbatim
 * ### from the WC. This causes nodes which the user meant to delete
 * ### post-replace to show up in the commit transaction regardless.
 * ### This is not a problem in itself, but because there is no
 * ### entry for a post-replace deleted node, we cannot send a
 * ### separate deletion to remove the post-replace deleted node
 * ### from the transaction after the directory was copied on the
 * ### server.
 * ### Worse, the entry comes back only after an update which
 * ### explicitly targets the node which is now locally missing
 * ### but present on the server, in a revision the WC thinks it
 * ### has the entire state of! By not handling the
 * ### locally-added-inside-of-a-replaced-parent-directory entry
 * ### removal case properly, the client corrupts the WC meta data
 * ### without realising the mess it just made.
 * ###
 * ### So our ignorance about post-replace deleted nodes here is
 * ### just a side-effect of a much bigger problem, which has existed
 * ### for some time (at least since 1.5.x, probably much longer).
 * ###
 * ### WC-NG should fix all of this before 1.7 release.
 * ### Note that, in trunk, the entry of post-replace deleted nodes
 * ### does not get blown away, so trunk is one step ahead of 1.6.x
 * ### already. */