0x means the following digits are in hex (base 16) rather than decimal.

0x0F is the same number as 0xF. Documentation would represent that as 0x0F rather than 0xF to highlight the fact that there are more than 4 bits in the binary form of the command number (I'm guessing there are 6 bits in this protocol).

Jon decoded the 16 bits of each of those signals from the samples at Premise. The first eight bits were 11001010 in each case. Those might represent a device number to distinguish commands meant for this device from commands meant for some other device using the same protocol, but since we don't know of any other device using the same protocol, that theory is hard to check. We don't really need to know what the first eight bits are for, just that they're there.

The parity bit is just a form of checksum, so if some random glitch messes up one bit of the signal the receiver will know to ignore the bad command rather than thinking it is some other command.

The toggle bit is more serious. If I'm right, there are two forms of each command and the receiver is designed to never believe the same form of the same command twice in a row. That's a big problem for using learned signals. There are a few possible work arounds, but first you should confirm (as I described above) that the orriginal remote really does alternate between two versions of each command.