I tried to add qs8 code bits to build 48, including commits #49 through #59, and they led to the page fault problem as discussed previously. It's caused by either the dithering table, turbulent8 asm, added audio asm, or another code fragment. I assume that adding new features is not easily supported by the DOS memory model.
Edit: with engoo v228d source code, and ability to reproduce a working dos binary, it may not be too difficult to find the differences between v228d and the current engoo version. Then, code bits could be added which correspond to the newer dynamic lighting code until reproducing (or not reproducing) the "duplicate generation of the 15bpp lookup table". I also should have mentioned earlier that the older v228d (dynamic) colored lighting only worked without the -no18 parameter - adding it led to inability to see world textures.
The colored lighting appeared very different between engoo and qbism, but I assumed that qbism employed some heuristic. In retrospect, your colored lighting method certainly seems closer to a realistic model.
Since adding any code fragments to qs8 build 48 (or engoo?) is causing page faults, and this has been reproduced a few times, it may be reasonable to think that both versions are running against limited memory. I've seen conflicting ideas as to whether another compiler would help a memory situation.
I'm sure this has been thought about, but is there a way, if it hasn't been done already, to employ the existing assembly code in any colored lighting code?