Firstly, I think the concept of creating a language or adding a built-in specifically for a challenge just to get a solution in one (or zero) bytes isn't even cheating; it's just boring.
What's the point in golfing if all you do is write a fancy long solution, make your program just require an empty input file and call it an interpreter?
I think answers in such languages should be allowed and eligible to win as long as the language was created/updated before the challenge, but still I'd recommend the creators of the challenges to listen to their conscience before accepting any "cheating" answers.
More general-purpose additions to the language just before posting a challenge, like the golden ratio example from Luis, shouldn't hurt that much, but if you implement something that clearly won't be useful later, it seems like plain old cheating to me.
After this point, my answer will be somewhat off the question, and more of a reply to Martin. (Sorry about the wall-of-text.)
I partially agree with Martin in that we shouldn't always compete between all languages. However, I think that competition between somewhat similar languages is a healthy feature of code golf. For example, languages could be divided like this:
- the "cheating" languages
- the "meant for golfing" languages
- Pyth, CJam and all the other old & new ones
- the "usable for golfing" languages
- Python, C, Haskell, TI-Basic and friends
- the "bad for golfing, but still fun" languages
- Java, C# and other verbose ones
- the "challenging to use at all" languages
- Brainfuck, Befunge, Malbolge, Shakespeare and other, mostly esoteric languages
I'm not saying this should be any sort of official system; I think most people will still agree that the languages in these groups will often compete at totally different levels. While competition between, for example, C# and CJam, is often rather useless, competition between Java and C# is not, just like between Pyth or CJam.
Contents still need a winner (especially in the SE system where you can only accept one answer), so accepting the shortest valid answer seems like the best practice to me. I do like the idea of not finding the shortest solution though; for example, not accepting any answer to mark it as a "winner" could be an idea.