unexpected mergeinfo results (v1.6.13)

Hi all,

I'm currently trying to clean up explicit mergeinfos that are scattered throughout our repository.
Some of these explicit mergeinfos were created because people used sparse working copies and didn't know about the impacts.
So I'm trying to locate the pathes that contain non-inheritable mergeinfos, check that those merged revisions didn't affect the children of that path,
and redo the merge with the -record-only option for that path. This way, I hope I can eliminate the non-inheritable mergeinfos as first step of the cleanup.

I've attached a perl script, that will reproduce a sample environment (it needs svn and svnadmin to be in your path).
It creates (in your current working directory) a repository and a working copy. The script creates some test data, creates a feature branch,
simulates some work (including cherry-picking from trunk to the feature branch) and at the end, it merges the branch back to the trunk.
Last but not least, it creates a cleanup branch.

This is the point where I am with my productive repository, and it turns out, that the cherry-picked revisions cause the behavior I wouldn't have expected.
The following is the session I use to reproduce the work till the point where I'm unsure if svn does things right.

# creating the test data
c:\mergeinfo>mergeinfo_fixture.pl
c:\mergeinfo>dir
Verzeichnis von c:\mergeinfo

28.10.2010 20:33 <DIR> .
28.10.2010 20:33 <DIR> ..
28.10.2010 20:28 2.108 mergeinfo_fixture.pl
28.10.2010 20:33 <DIR> repo
28.10.2010 20:33 <DIR> wc

# navigate to the cleanup branch
c:\mergeinfo>cd wc\branches\cleanup

# checking for the non-inheritable merge info
c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1
/branches/feat_1/folder_1:2-6*
/trunk/folder_1:4*

So here it is. My understanding of the mergeinfo and the mergeinfo elision is, that once these revisions get merged into the children of that path,
the explicit merge info should disappear. So I'm trying:

(first with svn 1.6.12, which behaves the way I expected it to work)

c:\mergeinfo\wc\branches\cleanup>svn -version
svn, version 1.6.12 (r955767)

c:\mergeinfo\wc\branches\cleanup>svn merge -r 3:4 --record-only "^/trunk/folder_1" folder_1
c:\mergeinfo\wc\branches\cleanup>svn status
 M folder_1

c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1
/branches/feat_1/folder_1:2-6*
/trunk/folder_1:4

So we see: r4 is no longer been marked as non-inheritable, but since it still contains other non-inheritable mergeinfos,
the data is still stored as explicit mergeinfo. I'm fine with that.

(now the same with the newer svn 1.6.13)

c:\mergeinfo\wc\branches\cleanup>svn revert . -R
Reverted 'folder_1'

c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe" --version
svn, Version 1.6.13 (r1002816)

c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe" merge -r 3:4 --record-only "^/trunk/folder_1" folder_1
c:\mergeinfo\wc\branches\cleanup>svn status
 M folder_1\file_1
 M folder_1\file_2
 M folder_1\file_3

c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 -R
folder_1\file_1 -
folder_1 - /branches/feat_1/folder_1:2-6*
/trunk/folder_1:4*
folder_1\file_2 -
folder_1\file_3 -

Now, this is what I don't understand. I merged (well, recorded) the changes of revision 4 into a fully recursive working copy.
The result according to the new client is, that the revision was only merged down to folder_1, not into its children.
Those instead get an explicit, empty mergeinfo property set, which means: "Nothing has been merged to me so far".

I'm unsure if this behavior is intended. It's correct that none of the changes would have ever touched those files,
but didn't I tell svn to record that the revisions should be marked as merged? In my opinion, it simply refuses to do that (the 4* still exists),
plus it adds more explicit mergeinfo to the childs (something I can't understand right now, but maybe it makes sense).

So what do you think? Is this behavior intended or did something go wrong between v1.6.12 and 1.6.13?
Or maybe am I missing some important point?

Thanks in advance!

Greetings,
Ben