Watch out for those pattern bits

Ball Launcher, the first boss in Launch Base 2's gauntlet, has this "lid" that swings open before each of its titular balls are launched, which also doubles as a platform Sonic and Tails can use to reach the boss. When the boss is defeated, the lid's segments break off from one another and fall in the water, but in doing so also take on a strange color:

The offending code is at loc_740AA:

loc_740AA:
    move.l  #MoveChkDel,(a0)
    bset    #7,$2A(a0)
    move.w  #-$5BDB,$A(a0)
    ...

Argh, another one of those goofy numbers that aren't really negative. This one gives us some insight, though. Setting the sign bit on $A(a0) equals setting the priority flag on the object's sprites, which lines up with what we see in-game: the lid segments usually disappear behind the wall, but pop in front of it when we defeat the boss.

If we flip the signage, we get the value $A425. Unpacking this gives us base tile $425, no X/Y flip, and color palette 1. Let's compare this with the setup code for the object.

loc_73CD8:
    lea     ObjDat3_74140(pc),a1
    jsr     (SetUp_ObjAttributes).l
    ...

ObjDat3_74140:
    dc.l Map_LBZEndBoss
    dc.w $4425
    dc.w $280
    dc.b 8
    dc.b 8
    dc.b $E
    dc.b 0

The second entry in ObjDat3_74140 holds the value $4425, which when unpacked gives us base tile $425, no X/Y flip, and color palette 2. And therein lies the problem: when the boss is defeated, the lid segments try to set their priority bit, but also accidentally change from palette 2 to palette 1 in the process.

A possible explanation is that the object did use palette 1 at one point, but when it changed, they neglected to update the value at loc_740AA. Either that, or it was just human error inputting the new value by hand. A more sane approach would be to just use a bset or ori instruction to set the sign bit without messing with the rest of the attribute.