Session state maintance (by default) requires proper cookies to be sent between each client and the server. If these cookies are not proplerly maintained session state will not work as expected. It is not unheard of for a proxy server to mess with cookies on requests going through them. The the proxy server is caching cookies or in some other way causing the cookies to be shared amoung users, the problem you are describing would exist.
the jury is still out to a degree, but i think we've identified the culprit(s) of our session bleed for anyone interested. it boiled down to two problems.
1. var scoping issues. unfortunately this was a fairly old application, written before we strictly employed best pracitices on var scoping variables within functions in all our cfc's. we've fixed the bad code and our session bleed problems seemed to have stopped. there is a great utility for checking code for var scoping problems available at: http://varscoper.riaforge.org/
2. a misunderstanding of how cflock with a timeout setting (and no throw on error) behaves. aside from session bleed, it turned out we had another issue in there, which was expected session values missing all together. the crux of the problem is that we had set our cflock read/write timeout's to 30 seconds. under the extremely heavy load, requests were routinely exceeding those timeout thresholds. the locks were not set to throw on error, so when the timeout threshold was exceeded, the code within the lock ended up just being skipped. this was leading to missing data in the session. temporarily we've simply increased the timeout setting to a large number, which has fixed our problem. eventually we'll set these locks to throw on error and handle the exception in a more graceful manner.
hope this helps someone.