When running a web site that has grown to the point that it has too much traffic for a single server, it is common practice to put a load balancer in front of the servers.
Unfortunately, there are all sorts of subtle problems that crop up that you may not notice at first. Most of them come down to sticky session issues (or lack thereof) and the fact that many web apps store session data in server memory. When a browser makes a request to a new server, it doesn't know anything about that browsers session, so a new session is created in memory and the user may experience weirdness: logged out, re-authenticated, losing their shopping cart, etc.
Most load balancers can be configured for various methods of sharing traffic: round robin, least connections, etc. Also, they can usually be configured to not move a client to a new server if it already has a session on one. This can be done via IP address or a custom cookie inserted into the
What I have done at the last two companies I've worked for is recommend that our clients do not use SSL SessionID as the way of tracking sticky sessions on web servers, but instead using IP address. This works in nearly all cases and has few downsides. The other solution is to use some sort of session sharing on your web servers to mitigate the issue (which also means that your web servers aren't a point of failure for your users' sessions). (One of the products I supported had no session information stored on the web servers, so we could safely round-robin requests, the other product could be implemented with a Session State Server... but in most cases we just used IP address to load balance with). The other solution is to configure your load balancer to terminate the SSL tunnel. You get some other benefits from this, such as allowing your load balancer to reduce the number of actual connections to the web servers. I've seen many devices setup this way.
One thing to consider through this is that - due to the way internet standards work - this really can't be termed a bug on anyone's part. There is no guarantee in the SSL/TLS standards that a client will return the same SSL Session ID for each request and there is not requirement that subsequent requests will even use the same tunnel. Remember, HTTP is a stateless protocol. Each request is considered a new request by the web server and everything else is just trickery to try and get it to work the way you want. You can be annoyed at Safari's behavior, but it's been this way for over 5 years by my count, so I don't expect it to change.