I don't see why it wouldn't be a valid implementation of C by simply defining things that C doesn't fully define.
There's nothing about the definition of "undefined behaviour" that prevents you from defining it in your implementation.
(And if you don't want to depend on the new behavior, which was previously undefined, then there's not much point in using this particular implementation.)
You have now created a new spec. Really a new language. Your users will make programs that rely on this new specification. Such code will no longer be portable to other standard C-compilers. Their programs might only be well defined in your new language, not in standard C.
For instance he talks about a C that default initializes all memory to zero. A program that relies on that will no longer be portable to other C compilers. If its no longer portable, is it really the same language any more?
I'm also not saying that's inherently a bad thing.
I'm not sure this is helpful though. We've accepted "literally" also means "not literally" without creating a new language.
http://waste.typepad.com/waste/2014/07/on-a-popular-misconce...
It's just a figurative use of "literally". It's like saying "He's such a baby" of an immature (<- also figurative!) adult. You aren't saying that such an adult is actually a baby.
The trick is to try to bring together all of these dialects in a way that everyone can in fact understand. This is why writing language specifications is _hard_.
And even afterwards, you can still choose a dialect over the standard. You'll just lose a certain segment of your audience. That may or may not matter for your purposes.