I've been reading the "Pentium ® Pro Family Developer's Manual" Volume 3 a bit (I was checking out SMM stuff originally, to check for bugs), but eventually got a bit distracted and looked into VME, at Page "12-15":
At table 12-2, it says:
Method 3, VME 1, IOPL <3, Bit in Redir. bitmap X: General protection exception (This is the same as non-VME behaviour.)
Method 4, VME 1, IOPL 3, Bit in Redir. bitmap 1: Interrupt from Virtual 8086 mode to Protected mode:
This is just plain V86 to Protected mode interrupt transitioning, pushing the extra segment registers (GS,FS,DS,ES onto the PL0 stack and clearing them additionally, as the 80836 programmer's reference manual describes)

Method 5, VME 1, IOPL 3, Bit in Redir. bitmap 0: Redirect to 8086 interrupt:
Clears TF flag, Pushes flags after clearing NT and IOPL (Clearing IOPL is suddenly allowed here?). Pushes CS and IP. Loads CS and IP from interrupt vector table at linear address 0. Clears IF flag.

Then for Method 6, it gets odd:
Method 6, VME 1, IOPL 3 Bit in Redir. bitmap 0: Redirect to Virtual 8086 Interrupt with VIF and VIP flag support:

VIF flag clear or VIF flag set and NMI or exception occurs
- Interrupts and exceptions handled in same manner as method 5 (So an 8086-style interrupt occurs even though the VIF flag is cleared? Isn't this supposed to be method 4 instead?)

VIF flag set and maskable hardware interrupt occurs
- Performs a method 4 style call to the #GP exception handler (So this is just normal interrupt handling for the underlying OS, in normal protected mode? Just ignoring the "INT" instruction special mechanics?)
- Handler sets VIP flag in EFLAGS image and returns to 8086 program.

VIP flag set when VIF flag is cleared with CLI instruction
- Performs a method 4 style call to the #GP exception handler (Huh? VIP set and VIF clearing causes a fault on CLI? Isn't this on STI instead? (in fact this is what UniPCemu does, on STI, not CLI?))
- Handler clears VIF and VIP flag in EFLAGS image and returns to V86 program.

So what is the truth in this case?

Looking at the old article by R. Collins, he also mentions that IRET doesn't handle the Trap flag (unlike POPF), but Bochs' emulator code does actually handle the trap flag in IRET?
http://www.rcollins.org/ddj/Mar98/Mar98.html

The IRET instruction behaves exactly as the POPF instruction does with respect to EFLAGS.IF, EFLAGS.VIF, and EFLAGS.IOPL. IRET and POPF differ in how they handle the trap flag from the stack image. If FLAGS.TF is set in the FLAGS stack image during POPF, a #GP(0) occurs; yet for IRET, the #GP does not occur.

So is Bochs incorrectly emulating said feature? Or is the unofficial documentation wrong?