Do we absolutely have proof that the original problem is caused for
sure by session key collisions? The assertion here is that we're
generating 10000 md5s and that NONE of those is unique and so the
function is timing out.

This is preposterous.

If this were actually the case, I could generate my own 10,000 md5s
and log into each of those users sessions as an attacker. Sessions
expire in 15 days. MD5 provides a reasonable distribution across the
namespace. If you've generated 10k md5s and NONE of them is unique,
you've got the md5 namespace pretty well covered (or you're using
really bad random input data, which we are not), meaning your session
key database has (conservatively) more than 10^20 petabytes of data.

Right.

The alternative explanation is that the cache backend is timing out.
The 10k loop fix basically masked that issue by trying a bunch of
times till it got a response. The fix for this issue is going to lie
in improving behavior when the cache doesn't respond properly, not in
fixing the key collision problem.

Additionally, UUID4's are only very probably unique. You are proposing
to move to a 103 bit random value (after excluding the fixed bits)
instead of the existing 512 bit value.

I predict that a patch which removes the 10k loop will make the
problem worse, with or without UUIDs.

Sorry to be blunt, but lets tackle the real problem here, rather than
making things harder for ourselves.

Best,
-Paul