I have a machine with a number of packages, including:

apr (0.9)
subversion-base
apache2

pkg_chk reports:

devel/apr - apr-0.9.12.2.0.59nb2 < apr-1.2.8.2.2.4nb1

and so 'pkg_rolling-replace -uv' does make replace package clean in
devel/apr, which happily installs apr-1.2.8.2.2.4nb1

Then, subversion-base and apache2 are both broken due to wrong
shlibs, but they are marked unsafe_depends=YES, and pkg_rr will
get to them and replace.

But, one can't install both apr0 and apr1, subversion-base by
default wants apr0, and apache2 wants only apr0, so builds of both of
those fail.

The fix is to delete apr and reinstall apr0, but then this happens
again.

Clearly something is wrong, and it's a bit hard to say what.
Candidates are (with not necessarily balanced arguments):

  apr naming:
 
    It seems apr0 is the "standard" version, and apr1 is the "living
    on the edge" version, despite ASF's claims that 2.2.x is now
    'standard' and 2.0 "legacy".  So therefore renaming apr to apr0
    was premature.

  default apr choice and apache naming:

    If apr 1.x is standard, then subversion should just use it by
    default.  And www/apache should get 2.2, with apache20 and apache1
    the old ones.

  pkg_chk:

    pkg_chk should realize somehow that a user running apr-0.9.x which
    is current with respect to the devel/apr0 package is not really
    out of date in the usual sense.  Clearly somehow one decided to do
    this, and branch jumps aren't really something pkg_chk should do
    for you.

  pkg_rolling-replace:

    This should figure out all of the above and do the right thing
    somehow.  An argument for why it's not pkg_rr's fault is that
    using pkg_chk to do updates has more or less the same issue.  

On balance, I think:

1) pkg_chk should somehow not demand that apr0 be updated.

2) The naming of apr0/apr(silent 1) should be consistent with
   www/apache being 2.2, and 1 and 2.0 available as apache1 and
   apache20, and subversion-base should use the unsuffixed apr.

3) The Apache people should have made a way to have apr be able to
   install multiple versions at the same time.

4) It would be really cool if pkg_chk knew how to find (e.g. after 2
   is done) www/apache20 from an installed apache-2.0.59 built from
   www/apache2 from before 2 and do the right thing with asking for
   updates and pointing to www/apache20 as the place to 'make
   replace'.

This is hard, so I don't mean to sound too cranky.  But I'm getting
used to pkg_rolling-replace just working, and thus coming to view
times when it doesn't as pointing to a bug somewhere.