I would like to get feedback on this proposal, where client application can read status of a command and to be able to retry if it was never sent over the wire.

var policy = Policy.Handle<RedisTimeoutException>(p=> p.Commandstatus == CommandStatus.WaitingToBeSentToRedis)
.Or<RedisConnectionException>(p=> p.CommandStatus == CommandStatus.WaitingToBeSentToRedis)
.Retry(3,(exception, retrycount) =>
{
    //log("Try {0} failed with {1}", retrycount, exception);
});

try
{
    policy.Execute(() => conn.GetDatabase().StringGet("test"));
}
catch (Exception e)
{ 
    //log
}

I'm not sure that handling retries that way is a good overall approach, since often we'll lose them in-flight with a disconnect. The proportions of course subject to throughput and latency. That being said, I'm not against having this information on Message, but adding the calls here would have an impact on maximum throughput (however slight, but still).

@mgravell, thoughts? This information could lead to more informative error messages and debugging for sure.

This looks good to me; merging