The current meta consensus is that the implementation defines the language. The cannonical answer is: What's the policy on interpreter bugs?
I think this is too rigid: I think that a specification should also be able to define a language, if and only if the specification is sufficiently rigorous to uniquely define the behavior of a given program, and sufficiently clear that essentially anybody reading it would come to the same conclusion.
For example, consider this question: Old Languages with new implementations
A user would like to use a cellular automaton that was defined 17 years previously. A cellular automaton is a very well specified kind of language, where every possible detail has been specified in advance. The specification allows one to know exactly how the program should develop in any possible initial condition.
Other specifications that are similarly precise include the definition of a Turing machine, various grammars, some assembly language specifications, the BrainFuck specification, and so forth.
Less precise specifications, such as those accompanying most general purpose programming languages, would not define a language, since it's not clear how a given piece of code may function.
I prefer the system outlined above because I think our current rule strays into "That's the rule because we said so" territory. I think the system outlined above avoids the problems associated with accepting specifications too lightly, while allowing them to be used in appropriate circumstances.