Just because the comprehensiveness of something is on a spectrum is not a reason to just not bother and have none at all.
Also, when done well a spec is a great way to learn & understand the language too. http://golang.org/ref/spec is so much more usable than Typescript's docs.
I agree that specifications are useful. I also think they're often presented as a panacea. It is important to acknowledge that they're a tool, with pros and cons, like any tool. The existence of a specification does not immediately mean that any and all ambiguities are resolved.
If an implementation isn't doing what you expect, is it just an issue with that single implementation? A problem with all implementations? A problem with what you expect? If another implementation does do what you expect is it correct or just lucky?
A spec resolves such discrepancies. Indeed, the spec may be where the problem is, but once the spec is corrected then implementations know what they must do. Absent of a spec, who knows?
1.It's not doing what I expect.
2.Is it intentional behavior or a bug?
3. Let's ask on github/reddit etc
With Special:
1. It is not doing what I expect
2. Is this a spec issue or code issue?
3. Let's check spec.
4a. "Working as specified". Shit. Hope spec improves in future versions
4b. It is not working as spec says. Let's file a bug on tsc.
And that is the difference.