That's a very subjective question, and probably not a good fit for StackOverflow so imagine this will get closed. But here's my two cents...
Full disclosure: I primarily use Apache.
For a start let's address one of your incorrect points: Nginx wasn't designed to solve HTTP/1 problems. Nginx was designed to solve some of the scalability problems of previous web servers by being based on an asynchronous, event-driven model. Under HTTP/2 there should be less connections per client, which you could argue makes scalability less of an issue as each client uses only 1/6th of the resources they did previously - but that's probably a little simplistic. Apache has an event-driven MPM module for years now too (though often not turned on by default in case of any thread unsafe PHP applications - but this would also be a problem with Nginx!). This brings them more back in line, though there's still a lot of debate about this and many say Nginx is still faster. In my experience, unless you are dealing with truly huge volumes (in which case you should be looking at CDNs, load-balancers and cache accelerators), few will ever notice the difference between Nginx and Apache. This is especially true when downstream applications and systems come into play - a slow PHP application will quickly negate any performance or scalability issues at the web server level.
Anyway, back to your main question:
For HTTP/2 support, my choice would be Apache over Nginx. It has had better HTTP/2 support for some time. Nginx only added HTTP/2 Push support in early 2018 for example, whereas Apache has had that for a number of years now. Apache also supports a PushDiary (based on the now-abandon Cache-Digests proposal) to prevent pushing resources that have already been sent, supports 103 Early Hints for pushing early, and push prioritisation options. Moving on from HTTP/2 push, Apache also supports using HTTP/2 in proxy mode (though it's still marked as experimental and the usefulness of this is questionable at the moment), and HTTP/2 over HTTP (h2c - though again usefulness is questionable since browsers do not support this). I also find the main developer of the Apache HTTP/2 implementation very responsive on the GitHub page for the mod_http2 module (included as part of core Apache since 2.4.18 and no longer marked as "experimental" since 2.4.26).
On the flip side, I understand that Cloudflare uses a customised Nginx based web server, and they have HTTP/2 push for over a year now (it was them that backported this implementation to Nginx). So, given Cloudflare's scale, that speaks volumes to the implementation of that though not sure how customised it is from the core Nginx code.
There is also a HTTP/2 conformance Testing tool available and when I ran this against some common HTTP/2 servers (for a book I wrote on the subject btw) I got the following results which clearly shows Apache as the most compliant with the spec:
![Which is the most compliant HTTP/2 server?]()
Now to be fair, most of the causes of errors are in not responding correctly to bad requests, that in a perfect world should never be sent anyway so aren’t that important. But still, we don’t live in a perfect world, and error checking is an important part of technology so I for one would certainly prefer the more compliant server. Similarly as pointed out in the comments below, the tool and web servers themselves, can be subject to race conditions and other problems which may incorrectly report errors.
Ultimately you are best choosing the implementation you are most comfortable with. The general feel has always been that Nginx is lighter and easier to configure, but on the flip side perhaps isn't as fully featured as Apache because of that. HTTP/2 support seems to continue that theme. If you want to play with upcoming HTTP/2 features then, to me, Apache definitely has the edge at the moment (though nothing to say that won't change in the future). However, for the basic use cases of HTTP/2, they probably can be considered similar. Even HTTP/2 Push is not used much yet, and there are serious concerns it could degrade performance if not used appropriately or due to implementation issues, which is probably why it has not been a priority for Nginx and while they only implemented it later.
