We've run into issues like this before with other new options like this, where they end up set only for normal HTTP/1 and not for HTTP/2 allowHttp1 (e.g. #59924).

What would happen if we called HTTP1's storeOptions here directly somehow? That would give us a single place to define the HTTP/1 options that affects both cases.

Right now we're duplicating the options logic, occasionally breaking things along the way, and creating slightly inconsistent behaviour throughout: for example this new code supports options.keepAliveTimeout if set, but we don't use options.headersTimeout in the equivalent options above - we just use a fixed default. It would be great to solve these kinds of issues permanently & consistently.

Imo: if allowHttp1 is set, we could just support all the HTTP/1 options here, in the same way as for an HTTP/1 server. Unless there's some specific case that we can't handle or that's incompatible? I can't see one.

If we want to be explicit & avoid any risk of conflicts in future, we could use separate http1Options option for this (only used with allowHttp1, so let's throw if it's used without that):

http2.createServer({
  // ...Http/2 options
  allowHttp1: true,
  http1Options: {
    keepAliveTimeout: 60_000,
    incomingMessage: ...
  }
});

We would then doc-deprecate things like options.http1IncomingMessage that mirrors HTTP/1's options.incomingMessage, as people could use options.http1Options.incomingMessage instead.

This is a bit more complicated and needs some thought & testing, but I think there's a reasonable solution that's reachable there and it would be great to stop patching the same problem over & over again.

+1 to this. My comment above was to somehow get the two implementations closer, but in hindsight this is also tricky, because eventually another issue/PR would be raised for yet another option. Calling storeHTTPOptions would be great.