Change:
The pseudorandom key PRK_2e is derived with the following input: <del> The salt SHALL be a zero-length byte string.  Note that RFC5869 specifies that if the salt is not provided, it is set to a string of zeros (see Section 2.2 of RFC5869).  For implementation purposes, not providing the salt is the same as setting the salt to the zero-length byte string (0x). </del> <ins> The salt SHALL be TH_2. </ins> The IKM SHALL be the ephemeral-ephemeral ECDH shared secret G_XY (calculated from G_X and Y or G_Y and X) as defined in

Discussion:
Not sure this change is practically needed, but it is a simple change does not hurt. Actually simplifies the specification as the discussion on HKDF and empty string can be deleted.
No disagreement recorded - merging now.
The nonce used for the computation of PRK2e in the key schedule is set to be an empty. By replacing this empty string by the sid of the session, this makes the key PRK2e linked to the session connection identifiers and divides the chances for an attacker to correctly compute the key PRK_2e by the number of running sessions. More precisely, considering running sessions, computing Extract("",Z) with a random Z, the attacker may have a match with any of the sessions. While considering using a sid, computing Extract(sid, Z), the attacker may have a match only with the session using this sid.
This would increase the reduction bounds for PRK2e, but would it make a change if we consider the actual keystream? (and latter keys) As the transcript is included inside the derivation, the keystream2 does depend on all the information exchanged that could be used to build an sid. At a high level, the question is kind of the following I guess: is it better to do vs ? (I have no clue about the answer, but I would guess that if we rely on the PRF assumption, it is mostly the same?)
Making the following change would be relatively easy: But as charlie-j points out, TH2 is already included in all the Expand() derivations, so I am not sure that adding TH2 improves the practical security. For the inclusion of SID to make this "attack" harder the size of the curve would have to be smaller than the size of the hash function output. For the X25519-SHA-256 combination that is true but the size of X25519 is still 2^252. Brute forcing that would be much harder than brute forcing the typically 128 bit OSCORE key or breaking X25519 with Pollard's rho.
For comparison, below is how the TLS 1.3 key schedule looks like without PSK
This is not really true for the current: But would be true for
If we interpret in this quote as covering the PRKs, it is not true for any of them apart from PRKout, as similarly TH3 and TH4 are included only in K3 and K_4.

Good point. Let's see if we should reformulate "and all symmetric keys are derived using as much previous information as possible" is some way
The keys (and actually random material) that do follow this specification are the one form the key derivation figure: So an option would be to simply point at the figure?
Making a PR for this I noticed that this change has the benefit of allowing the text talking about HKDF and using the empty string as salt. Irrespectively of if the extra security factor is needed or not I therefore think this change should be done. There does not seem to be any negative affects of the change (except that it affects the test vectors).
PR is included in -16