1) With Keep-Alive :
According to this wikipedia article (http://en.wikipedia.org/wiki/HTTP_pipelining) it is the opposite : implementation on the server side is actually very simple. I believe this affirmation is based on the assumption that a single thread is used to handle all requests for a single connection (which was certainly the general case when this mechanism was designed) and thus several requests on the same connection are handled sequentially by this thread (and as TCP guarantees ordered delivery, responses are naturally received in the same order they are processed). It might be different today on a non-blocking server implementation.
2) Without Keep-alive :
Without keep-alive, you do not pipeline requests, so I do not see the race condition. You have two separate connections for requests A and B, each connection is closed when the request has been completed.
If the client tries to pipeline requests without keep-alive, I believe the following section of the specification applies :
Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
My interpretation is that the server must legitimately discard the second request and only respond to the firts one, as responses are FIFO. It's up the client to resend the second request.
Keep in mind : this are mostly suppositions on my side, I hope they make sense to you!