The result will be the same, because the two above explainations are essentially the same
It just depends on how you deal with the data. With microcontrollers/CPU' you tend to deal with bytes, thus the '8-bit becomes 16-bit' part. I usually just use a lookup table, split a byte into nibbles, and encode each seperately, meaning a byte -> 2x 4-bit nibbles -> 2 'manchester' bytes.
However, if you're dealing with pure logic, CPLD's/FPGA's then generally these will work on a bit-by-bit basis, encoding each bit on its own, by reading it in, then switching to its compliment. But with that method, the datarate out is double the datarate in, because its purely serial, no storage of bytes anywhere.
As for 'standards', I've seen both 0->01, 1->10 AND 0->10, 1->01 used. As long as your tx and rx agree on the rules, it'll be fine. The whole point of manchester/biphase encoding is that each bit has a transistion in the middle of it, making it self-clocking, synchronous. Very reliable, easy to do, but you pay the price for doubling the bandwidth used, or halving the available datarate (because you're sending two 'chips' for every data bit).
There are other methods varying in complexity (4B/6B, 8B/10B, data whitening), but manchester is a great place to start for RF/DC-balanced comms.
I'm a complete newbie with C at the moment, so I can only suggest maybe a case statement, but deffinately working on a byte-byte basis. That is, a routine that takes in a byte, but outputs two bytes, essentially working in parallel. I've seen plenty of C-based routines whilst googling for channel coding methods, I'm sure you'll find something. Google has (almost) everything.
Blueteeth