Emulator

I can reproduce this with the NTSC-U version (GMPE01 revision 1) which has a handy AR code that unlocks all minigames.

Confirmed that that fifolog renders correctly on real hardware but renders wrong on dolphin (using the hardware fifoplayer).

Note that the reflection of the rightmost penguin is also affected (but the rightmost penguin itself, and the middle penguin, are both not affected). This is a bit harder to see due to the white background (if the starting object is set to 62 it's a bit easier to see).

The penguins are drawn in the order right (166-181-186), middle (187-202-207), right's reflection (208-223-228), middle's reflection (229-244-249) (the numbers are first object in penguin, first object in penguin's body, last object in penguin's body. Note that you can't just use a range of 202-207 because the game clears the screen; the easiest range to use is 202-357 for instance). The right penguin uses position data from an array at address 00930180 (set in object 181/fifo offset 0003a36d, and the fifo recorder created a memory update at offset 0003a495/the end of object 181's primitive data), but the middle penguin and both reflections use position data from 0095e020 instead. The middle penguin sets the address in object 202/offset 0003ca53, and the memory update ends up at offset 0003cb7b at the end of object 202's primitives.

The right penguin's reflection sets the address in object 223/offset 0003f139, but the corresponding memory update ends up at offset 0003d36f - the end of the primitive data for object 206 (part of the middle penguin). And the middle penguin's reflection sets the address in object 244/offset 0004181f, but the memory update ends up at offset 0003fa55, the end of the primitive data for object 227 (part of the right penguin's reflection).

The fifo recorder does do some weird things with memory updates (they're being placed at the end of the primitive data, when they should really be at the start), but this issue happens in normal gameplay. I'm pretty sure what's happening here is that the game allocated two buffers (at addresses 00930180 and 0095e020) intended for the right and middle penguins (respectively), but accidentally uses the buffer for the middle penguin for the right penguin's reflection. The code was written under the assumption that the buffer for the penguin being drawn was separate from the one being updated, so they update what is supposed to be the right penguin's buffer while the middle penguin is being drawn. But both buffers are the same, so the backing memory for the middle penguin gets changed in the middle of the drawing process. (Note that I don't own a copy of Mario Party 4, so this is entirely conjecture based on what is happening in the fifolog. But it feels plausible at least.)

One other aspect is that the game issues GX_CMD_INVL_VC at the start of each penguin's body section (objects 181, 202, 223, and 244), and doesn't issue it again until it's moved on the next penguin's head. This command is used to invalidate the vertex cache. Since all of the drawing happens in roughly the same part of memory (and, objects 184/205/226/247 use index 0x61 into the array (corresponding to addresses 0x0095E4AC-0x0095E4B7) when the maximum index used in the next 2 objects is 0x63 (0x0095E4C4-0x0095E4CF) objects 181/202/223/244 use the maximum index of 0x63, so all of the data is in the cache), on real hardware the vertex cache is hit and main memory is bypassed (until the vertex cache is invalidated). So, that the game accidentally using the wrong buffer ends up not mattering.

I was able to confirm this with the hardware fifoplayer by issuing GX_CMD_INVL_VC after every memory update, effectively disabling the vertex cache, which results in the same behavior as in Dolphin. (I also separately tried clearing CP_VAT_REG_B's top bit, currently labeled as "Enhance VCache (must always be on)". This did introduce some kind of rendering oddity on hardware, but it was a different one from the one Dolphin had.)

So, to fix this, we would either need to implement the vertex cache (likely to require a bit of research, and it would probably have a performance overhead since I don't think Dolphin would actually gain any performance by being able to cache vertex data since the video backends probably wouldn't be able to make use of this information, but this would be good for accuracy purposes), or we would need to implement a game-specific patch (which I wouldn't be able to do without buying the game).