I see that this is correct from a spec point but it will cause trouble to correlate the response to the promise if two requests are sent with the id set to null. @AArnott how do you handle this? I would like to not allow this because I can't guarantee correctness.

StreamJsonRpc has had to interop with other JSON-RPC implementations that actually used null as the value for an explicitly specified id. Those other parties were buggy though, for related reasons. But we did build up some resilience to it to deal with it a bit better.
I think it's bonkers that the spec allows null, which I guess should be treated as a unique value just like any other number or string that might be used as an id. Perhaps if some implementation never sent two requests concurrently, they could just use id: null for every single request.
I wouldn't worry about correlating a response to the request if I were you. On the server side, you don't have to use the id to correlate anyway. And if you're on the client side, you get to decide what the ID is, so you can simply avoid ever using null as a request ID.

It was more for me to avoid that I ever create a request with a id being null. Since the library doesn't allow sending requests directly it will not cause harm. But I with change the code for createRequestQueueKey and throw if I receive a message with id null.