Mirrors my worries regarding VP8. Many people don't understand the codec world, but generally there is a standard, and several implementations of that standard. An example - the standard: MPEG4 Part 2. Most people have no idea what that is, but if you tell them "DivX", they know. But if you encode a film with the DivX encoder, you will find that the XviD decoder can decode it, because they both implement the same standard.
Why is this great? Well, compare an MP3 made by the FHG encoder with one made by LAME at comparable low bitrates. Despite the fact that they both play fine on your MP3 player, phone, pc, et al, the quality per bit is so different you would expect them to be a different codec. Having separation between spec and implementation allows others to make better, faster, more effecient (not necessarily all at the same time) implementations, and if VP8 needs anything right now, it's a better implementation.
As it stands, this can't happen, and imo calling VP8 competitive with h.264 is charitable.
1) Xvid cannot decode Divx as it is and vice versa. Althrough in theory they are both implementations of MPEG-4 ASP, they both have quirks that are their own only. The decoder has to deal specifically with Divx quirks and Xvid quirks, or else there's no picture.
2) There are two independent software VP8 decoders - libvpx (Google's original) and ffvp8 (ffmpeg). As for encoder, one is libvpx, which is usable today and the other is xvp8, which is in development. So yes, there will be independent implementations. There are also other, hardware-based decoders and encoders.
1) Yes, they can. If they couldn't my DirectShow stack would need to be a lot more complicated. I have decoded XviD with DivX and vice-versa without hassle. Maybe this is to do with profiles or something? I am happy to believe you could encode something with one that doesn't decode with the other, but in theory and in practice it seems to work out in most cases.
2) My worry is how different these can be without causing problems down the line. VP8 as a specification seems comparable to early days HTML, whereas MPEG-4 part 2 or part 10 (h.264) is more like HTML4.
1) In the end, both xvid and divx (and other, like ffmpeg or nero) decoders contain fixes for divx/xvid quirks. In software, it is easy. For extra fun, get your hands on some dvd players, that claim divx support. Yes, they can decode divx, but decoding xvid is much bigger problems for them (it is not about profiles, but about bugs in produced bitstreams).
Why is this great? Well, compare an MP3 made by the FHG encoder with one made by LAME at comparable low bitrates. Despite the fact that they both play fine on your MP3 player, phone, pc, et al, the quality per bit is so different you would expect them to be a different codec. Having separation between spec and implementation allows others to make better, faster, more effecient (not necessarily all at the same time) implementations, and if VP8 needs anything right now, it's a better implementation.
As it stands, this can't happen, and imo calling VP8 competitive with h.264 is charitable.