No, that's not quite it. SCI Companion generates this weird code for Bset:
procedure proc_003a
; (= oldState (Btst flagEnum))
003a:3f 01 link 1 // (var $1)
003c:78 push1
003d:8f 01 lsp param1
003f:41 e6 02 call proc_0028 2
0042:a5 00 sat temp0
; Take flagEnum and divide it by 16
0044:8f 01 lsp param1
0046:35 10 ldi 10
0048:08 div
0049:36 push
004a:9b 06 lsli local6
; Similarly, get the remainder
004c:38 8000 pushi 8000 // $8000 sel_32768
004f:8f 01 lsp param1
0051:35 10 ldi 10
0053:0a mod
; Compute $8000 >> that remainder
0054:0c shr
; OR the bit in
0055:14 or
; but wait, wtf is this?
0056:1a eq?
0057:3a toss
0058:60 pprev
; Store the corrupted result back
0059:bb 06 ssli local6
; (return oldState)
005b:85 00 lat temp0
005d:48 ret
Yay stack corruption: Companion seems confused about when (/ flagEnum 16) is on the stack, and when it's not, and starts throwing away random stack values (at code offset 0057). So you are right that the code ends up storing into the wrong variable, but it is due to improper stack handling. The eq?/pprev idiom could be quite clever under the right circumstances, but I don't see how it helps here.