Yep, this is a real issue. We currently rely on NIOHTTP1 to provide framing headers (including Content-Length), and as described by apple/swift-nio#2508, NIO currently can't handle this case properly. (Big thanks to @Lukasa for helping clarify this for me!)

What we can do is handle this in Vapor's part of the channel pipeline. I'll try to get a PR up for it shortly.

Belated correction: This is not an NIO issue at all. NIO actually does the right thing already here, and I misread where the problem was happening. It's actually an issue with how Vapor's Response is implemented. If you write your route like this instead, it works as intended:

app.on(.HEAD, "test") { req async in
    let res = Response(version: req.version, headers: ["foo": "bar"])
    res.headers.replaceOrAdd(name: .contentLength, value: "42")
    return res
}

(Note: The only critical change here is setting the content length separately; the other differences were just me removing redundancy.)

$ curl -i --head http://localhost:8080/test
HTTP/1.1 200 OK
foo: bar
content-length: 42
connection: keep-alive
date: Wed, 11 Oct 2023 17:09:23 GMT

There's nothing I can do about the awkwardness of this without breaking existing public API, unfortunately, so I have to close this issue as a wontfix 😕.