How hard would it be to implement support for lit liquids in hardware-accelerated engines? In software rendering it's easy, but software-rendered engines will never be the main target for any mapper nowadays.

I am really not aware of the technical difficulties, since I've never tried to learn how hardware-accelerated engines works. All that's needed is to draw both the lighting and the liquids in a single pass, using turbulent projection for the liquid texture and regular projection for the lighting, and combining them together before blending them into the framebuffer.

Support in mapping tools is almost there. The latest TyrUtils needs liquid brushes to be compiled as func_detail with _dirt -1, but hopefully this won't be needed anymore in the next versions.

I remember Spike saying that FTEQW also supports this, but several other engines would also need this feature.

it depends on the implementation.FTE just uses glsl for water, so its just a case of providing it with a second texture+texcoords that it can sample from just like any other lit surface.Without glsl, you just need to use multitexture to combine(modulate will do it, which saves trying to use register-combiners - this is separate from glBlendFunc) the two textures before it hits the screen (that's the glBlendFunc part). again two sets of texture coords. In vanilla its really no different from other lit surfaces, just with some per-vertex texture coord modifications.On the other hand, quakespasm's crazy render-to-texture implementation is crazy, but it should be fine to just sample from that warped texture in exactly the same way as any unlit surface.