Just tried running Windows 95 with the most recent bugfixes added(segmentation simplified to have the generic LOADDESCRIPTOR function only handle descriptor table faults (returning 0), page table faults(returning -1) or load success(returning 1).
Now the errors previously handled by it(invalid SS loads, invalid CS load type, invalid LDT pointer without LDT or written to LDT) are completely handled by the getsegment_seg(which is called by segmentWritten for protected mode loads(no V86 or real mode).
So that's working in the newly-ordered, correctly throwing faults(it should afaik).
Then I found some bugs in the new LSL/LAR/VERR/VERW instructions clearing zero flag without result written when the loaded segment descriptor(Using LOADSEGMENT calls as well) when the Present bit was cleared. This wasn't the case, according tp documentation. Removing said check and ZF becoming zero for that case, as well as fixing detection of invalid System descriptors with S=1(incorrectly clearing zero flag) and S=0 with 'conforming code segment' in the lower type bits(also when S=0) was fixed.
Then I noticed the documentation mentioning clearing of the zero flag for NULL segment selectors as well(even though ALL operation descriptions in all manuals I can find don't mention that at all?), I've modified it to behave clearing the zero flag for that as well(originally in my first commits forgetting the 32-bit LSL/LAR using a 32-bit memory block(oper1d), it actually checking the most recent 16-bit block(oper1) which was set by whatever function used that before the current instruction.
Now, having fixed those issues, I once again see the kernel throwing a blue screen instead of the kernel STUB error it was throwing since my descriptor update. And thanks to the improved segmentation faults and/or the improved LSL/LAR/VERR/VERW handling mentioned above, the fault address seems to have changed?