Bad interaction between svn and OpenSSH auto connection pooling

Background for the dev@svn list and the openssh maintainers: I'm
commenting on a Debian bug report, http://bugs.debian.org/413102, where
'svn log svn+ssh://...' sometimes encounters a broken pipe due to the
ssh subprocess dying too soon. I explain below.

[Peter Samuelson]
> It seems that in the 'svn log' case, the session pool, passed into
> [libsvn_ra_svn/client.c] open_session(), is destroyed too early, thus
> killing ssh. I'll try to investigate further.

OK, svn is not actually buggy. Here is what happens:

'svn log svn+ssh://...' fires off _two_ ssh processes. (Erik Huelsmann
explains on IRC that this is intentional, connections are treated as
lightweight, libsvn_ra makes no attempt to reuse connections for
efficiency.)

The first ssh process finishes its business and is explicitly killed
(by apr, when the session pool is destroyed). The second connection is
still active.

That would be fine ... IF the two ssh processes were independent, which
normally they are. But not if you use the "ControlMaster auto"
feature! This causes ssh to do its own connection pooling: the first
ssh process sets itself up as a "master" and the second one detects the
master and becomes a slave. People use this feature for efficiency,
since setting up and tearing down ssh connections really isn't cheap.
(There's the network protocol and the cryptography, but also password
prompting and such.)

So I'm still trying to think of ideas how to proceed here. It's really
not svn's fault that launching two ssh processes, then killing the
first, effectively kills the second as well. On the other hand, it's
not really ssh's fault that a master process is being explicitly killed
while still in use. (Left on its own, the master would wait until all
its slave connections are closed, before dying.)

Note, one workaround is to explicitly instantiate an ssh connection
pool master, with 'ssh -M', before using 'svn log'. Another is to set
SVN_SSH='ssh -o ControlMaster=no' (or the equivalent in
~/.subversion/config). Does anyone have any better ideas, for either a
fix or a workaround?

Thanks,
Peter