It’s not about stubbornness. Unless I’m misremembering you are a developer yourself, so you know that you can’t realistically change your whole software build toolchain just to include an alternative renderer, especially with a codebase as impressive as the WINE one.

The DXVK dev knew about that when they chose a language incompatible with the existing WINE codebase, so they knew from day one it could not be integrated upstream. This lack of inclusion is on them, not on WINE devs.

To avoid confusion: I am very happy that DXVK is a thing, it is useful for many games of the D3D10/D3D11 era. I would rather have the current suboptimal situation with DXVK unmergeable into WINE than no DXVK at all.

Not change, but they could at least make an effort to accommodate it. I think it's doable. But they didn't want to. Understandable on one hand (i.e. their idea is that if you want something better - build it yourself and add those dlls which anyone who cares to have good performance on Linux does). But on the other hand, they could make it more seamless.

May be another factor is project governance. dxvk and vkd3d-proton are independent of Wine and can make their own decisions and move fast. May be they didn't want to be governed by whoever makes final decisions in Wine project.

Language choice in my opinion is not a blocker for project inclusion though, and having strict requirement for C only is what I would consider stubbornness. But I don't think it's the real reason here anyway as above. More likely a combination of macOS problem and managing the project.

Not having to be online while the game runs sounds good. But unfortunately there's no database or any other kind of store for the game settings. The necessary tweaks are hardcoded in python scripts, not a good design choice.

As someone who works on software maintenance I can assure you that no, they could not "make an effort to accommodate it". This is not about willingness at all, but simply not technically doable without majorly disrupting WINE development and maintenance.

This is going to be my last post about this, as it seems we are running in circles here.

I would have dropped whole autotools from Wine and replaced it with a better build system first if that was my project. And then accommodated the above.

It is a big effort though and I surely don't mean that it's trivial. But it's not impossible.

Would it be possible to get an updated Underrail wrapper?

As far as I know, GOG does not provide a WINE wrapper for UnderRail.

it seems to work with Proton 8.0-1 and Proton 7.0-1.