There is only one byte of button code, the one you called "1st".

The byte after the button code is a check byte that is the XOR of the button code with the one and a half bytes before it.

The nibble of check byte that you say is always the same as the corresponding byte of the button code, happens to be the same in MOST (not all) of the signals in THIS (what Jon posted) list of signals, and then only because those nibbles of the preceeding bytes happen to be zero.

Based on incorrect reverse engineering I did years before I saw an official spec of this protocol, my software calls the byte before the button code "subdevice" and the byte before that "device". Many other programs in the JP1 group and here had adopted that convention before we discovered it was wrong, so it was easier to leave it wrong.

So in that list you see commands with "device" 128 and "subdevice" 0. Those two bytes have zeroes in their low half resulting in the duplication you described. But the ones with "subdevice" 4 don't have that duplication.

Actually the low half of the byte I misnamed "device" is really a check nibble for the manufacturer code and for Panasonic, that nibble is always zero. I forget the official meaning of the three nibbles that make up the other half of "device" and both halves of "subdevice", but those meanings have been published in a few threads at RC. When using generic tools based on reverse engineering of multiple disimilar IR protocols, it is simpler to ignore protocol specific meanings like that and cram almost everything other than function codes and check bytes into the device.subdevice paradigm.