Question: Rationale for always generating non-empty TLS 1.2 session_id when reuse_sessions = false

[zmstone]

This is a design / clarification question rather than a bug report.

I am looking at the TLS 1.2 session ID handling in OTP and trying to understand the rationale behind always generating a non-empty session_id, even when session reuse is disabled via {reuse_sessions, false} on the listener.

From RFC 5246 7.4.1.3, the session_id in ServerHello may be 0..32 bytes in length, and an empty value is legal and commonly interpreted as “no resumable session is being issued”.

However, in OTP:
• The server always generates a session ID on a full handshake.
• {reuse_sessions, false} prevents caching / resumption, but does not appear to affect whether a new session_id is sent.
• The no_server fallback in ssl_server_session_cache:new_session_id/1 already uses crypto:strong_rand_bytes(32), suggesting a random ID is considered acceptable.

This leads me to two related questions:
1. Why does OTP not send an empty session_id when {reuse_sessions, false} is set?
Is this for interoperability, client compatibility, TLS 1.3 legacy behavior, or historical reasons?
2. If an empty session_id is intentionally avoided, is there a reason OTP prefers the current “unique_integer + AES” construction over simply generating a strong random 32-byte value?
(Given that crypto:strong_rand_bytes(32) is already used as a fallback when no cache process is present.)

I am not proposing a change at this point — I am trying to understand the design constraints and trade-offs.

Any insight into the historical or technical reasoning here would be very helpful.