ssh client stays connected after remote forward fails to bind

I've tried to instruct SSH that the only purpose it has in life is to
provide remote port forwarding (hence the -N -T) but if the remote fails
to bind I get an error locally (Could not bind to remove address) and
the SSH connection stays open and the client running. I think the ssh
client should terminate at this point as there is no other channel open
nor any possibility of a channel being opened (say through dynamic port
forwarding).

Maybe this is user error on my part ? Would this be considered a bug or
a feature ? I'm using OpenSSH_3.9p1 in the client I've just investigated.

The scenario that causes this problem is that my previous ssh client
remote port forward is still active at the remote end, due to a half
open connection (my end was rebooted, but the remote end is still open),
so the TCP port is still bound and in use by the remote end, but its
only a matter of time before ServerAliveInterval=600 kicks in and kills
that connection. So my new ssh client instance reconnects and quickly
sees the failure to setup remote port forward it then just stays
connected (doing keep alives I guess) but with no useful purpose.

I am thinking that the ssh client could be better by implementing:

* Exit after the initial round of channel setups if they all fail
because there was no further work to do once the remote bind failed is
reported back. This should be the default IMHO with an option to disable.

* In the case there is another channel open (multiple forwards
multiplexed) then there should be a background timer which will
reattempt to execute the command line / configured port forwards that
are not currently available/active. This background timer should be
configurable in seconds in an option, I think the default should be 60
seconds or so, I can't think use case that would want the default to be
never (as it behaves right now, i.e. if you configured a forward and the
ssh client is still running then we can presume you want that port
forward to be setup ASAP, not a one shot attempt at startup that has
little practical use that I can see).