Automatic tree conflicts resolution during svn update

The current draft of the Subversion 1.8 Release Notes announces
automatic tree conflicts resolution for locally moved files and
directories. But it seems that this feature does not actually work in
RC2. The detailed reproduction script is given below. I think that we
should either drop this feature from the release notes or provide a
better documentation on how to make it work.

The current draft of the Subversion 1.8 Release Notes says the following:
[[
svn update, svn switch, and svn resolve can now automatically resolve
tree conflicts involving locally moved files or directories.
]]

But I'm unable to make it work. Experimenting with SVN 1.8 RC2 I'm
getting the following behavior:
1. Suppose that we have two simple working copies of repository with a
'Program.cs' file.

2. Rename the 'Program.cs' to the 'SuperProgram.cs' file in the first
working copy:
[[
svn move Program.cs SuperProgram.cs
]]

3. Modify and commit the 'Program.cs' file in the second working copy.

4. Update the first working copy using the 'svn update'.

5. Get the following conflict resolution message:
[[
Tree conflict on 'Program.cs'
> local file moved away, incoming file edit upon update
Select: (p) postpone, (mc) my side of conflict, (r) resolved,
        (q) quit resolution, (h) help:
]]

I do not consider this behavior as *automatic* because of the following:
* it requires user to make a non-trivial decision;
* there is no option like "resolve automatically";
* it requires user action for all moved files and folders.

So my questions are the following:

1) Is there a simple way to enable automatic conflict resolution
during the update? Am I missing something?

2) Should we drop (or reword) this feature from the Release Notes?

Thanks!

P. S. My own opinion is that automatic conflict resolution for moved
files is "The Number One Required Feature" for Subversion. I prefer to
have this feature released in SVN 1.8 (even only for 'update' and
'switch'). But I'm not sure that this is possible because there is
some push to make SVN 1.8 released quickly.

-- 
With best regards,
Danil Shopyrin
VisualSVN Team