MarkV isn't my engine although I did contribute code to the D3D renderer.

My own opinion is that MarkV is not the type of engine I'd make or use. I consider it as "collapsing under the weight of it's own feature-bloat", and I'd probably go straight to ripping apart the existing renderers and replacing them with a more modern, single API approach. 

But do you think D3D is the way to go? I don't even know what QS is using. It's certainly fast enough. In QSS, I found PK3 support useful since PAK is really outdated and does not provide any compression at all.

Just a bit disappointed they still didn't get that waterwarp effect working. But I guess many people can live without it if all those huge BSP2 maps out there run properly.

In general, I also prefer ports with simple features. There are many Mark V features I would never use, e.g. QMB particles or AVI capturing. What I like is the level selection via ingame menu.

I dunno if we need yet another port variation for Quake, but then again there can't be enough of them since the preferences are different for a lot of people. Personally, I'd settle for something that
can run most recent AD maps while also being able run all the classics flawlessly, including exotics such as Nehahra, Malice or Shrak, with LIT/VIS support, all limits removed, MP3/OGG soundtrack handling, authentic underwater warp, option for original weapon positioning, PK3 support, external texture support (if you really want to use those HD mods)... I think that's about it, at least for me. 

But do you think D3D is the way to go?

In 2020 I don't think it matters so much anymore. The state of OpenGL drivers is much better than it was 10 years ago, primarily because OpenGL itself has been mostly a static target for a long time now. That also means that you can more reliably depend on features up to version 4.x being widely available.

These days I think the main reasons to use D3D would be if you wanted to be different, or if you just prefer it as an API. Otherwise there's enough tradeoffs between both that it's pretty much 50/50.

In a Quake context, optimizing the shite out of an existing legacy OpenGL codebase pretty much involves a complete rewrite anyway. 

to make at least small adjustments to the code, e.g. prevent resolution change underwater in WinQuake?

I mean, we have the code on Github now since over a year, but nobody seems to be interested in doing anything with it, at least increasing limits or fixing small stuff. Which is sad. I would do it by myself if I could.