I don't know this code very well but I don't understand how that could work reliably. expectContinueReader is based on reading the request, so I don't see how the requester responder will be able to add any headers.

well, without having plotted out a detailed implementation plan it seems to me that the main thing here is that responsibility for writing the headers is leaked to the reader in the case of expectContinueReader, which is not ideal. The reader is invoking the write on the actual connection upon read:

func (ecr *expectContinueReader) Read(p []byte) (n int, err error) {
	if ecr.closed {
		return 0, ErrBodyReadAfterClose
	}
	w := ecr.resp
	if !w.wroteContinue && w.canWriteContinue.isSet() && !w.conn.hijacked() {
		w.wroteContinue = true
		w.writeContinueMu.Lock()
		if w.canWriteContinue.isSet() {
			w.conn.bufw.WriteString("HTTP/1.1 100 Continue\r\n\r\n") <--- this
			w.conn.bufw.Flush()
			w.canWriteContinue.setFalse()
		}
		w.writeContinueMu.Unlock()
	}
...

So essentially, if we can proxy the write through the actual response object in a dedicated method we could respect the headers that were written into it in the meanwhile. The only thing is that infers that synchronization is needed in order to make sure that no new headers are being written while the previous ones are being flushed to the client. We could get around this in order to get better performance if synchronization is the deal-breaker here, but let's first discuss if this is a viable solution at all.

I think this might help also make it easier to implement 103 Early hints.