Quakespasm is not in active development ATM. So there's that little issue. 

True, but FWIW folks shouldn't read that as "dead project". Updates were still landing in the codebase through the end of 2018. So nothing going at the moment, but Quakespasm development seems to come in spurts.

Dunno if those developers have ever commented on the likelihood of Nehahra support though. 

Poor Baker of inefficient coding, he might never return, man. :P We need him! 

Someone said somewhere that Nehahra is too much of an oddball to support properly. Too bad for me, haven't played it yet and Mark V doesn't run well on my system. 

In mark_v.exe (not _winquake), if a water brush is not at least overlapped by at least one unit by a non-water brush on one face, it will not render as transparent unless you activate r_novis 1. With developer 1, it claims that the level is not vised. In mark_v_winquake.exe, it does see the vis information and properly renders the water. 

I've played through Nehahra recently with Mark V and had no personal issues at all, just specify -nehahra in the command line. The fog and pretty much all graphical features work, the cutscenes do not mess up the HUD afterwards unlike the original executable, the custom music will not play however, maybe it doesn't support xm files but the cool outro music on epilogue texts between chapters does play. 

There's some funky things Nehahra does that technically work, but that it really shouldn't do. In other words, the kind of thing that normally comes back to bite you in the ass at some later date.

Two of the big ones will be that it uses a modified protocol but doesn't change the protocol version number, and that it relies on sending stuffcmd every frame for certain things rather than the built-in messaging or reading options from worldspawn. 

If you use winquake with vid_stretch 1 or 2, water in dopa has a bunch of lines through it.

https://imgur.com/a/8xyVixJ

To correct this you can set r_wateralpha to 1.

Figured I'd mention this in case it hasn't already been brought up. 

is normal behaviour on those maps which support it (the original game doesn't as standard) 

Ahh I see. Shouldn't winquake default this cvar to 1 automatically though since it doesn't support transparency? 

The lines you are seeing are the transparency. It's exactly the same transparency method used in old games such as Sonic 1 for the Sega Genesis.

However, I agree that it doesn't look good in MarkV. A stippled pattern would look better, as implemented in old versions of Makaqu. 

Shouldn't winquake default this cvar to 1 automatically though since it doesn't support transparency?
Stock WinQuake doesn't support translucency, but several engine mods have added it, of which MarkV is one.