I often argue against purely natural language specifications in favor code based specs. I just don't think human language is nearly precise enough to write an adequate specification. Natural language words are incredibly polysemic and contextual. Look, for example, at how many meanings the word "break" has: https://www.merriam-webster.com/dictionary/break
Kolmogrov has long ago suggested that fully specified information distills down to a computer program: https://en.wikipedia.org/wiki/Kolmogorov_complexity, https://en.wikipedia.org/wiki/Minimum_description_length
The ideal language for a pure specification might be a mix of natural language and pseudo code with a pseudo test suit. However, if you are writing that, you might as well go one step further and write working testable code.
I like the concept of Literate Programming (https://en.wikipedia.org/wiki/Literate_programming) and its descendants of having code with extractable inline comments that auto generate documentation. I would argue that modern pull request based workflows that tie discussions to version controlled code changes are also the progression of this line of thought. A cleaned up version of these might make sense for a specification.
And I get some of the concerns. While natural language under specifies, reference implementations over specify. This is more of a problem with low level languages however. Modern high level languages are getting fairly close to a form of pseudo code. I fully agree that the reference implementations shouldn't contain or should hide, low level optimizations. I also understand that reference implementations can unduly tie specs to specific hardware, OSs and platforms.
But to me, over-specification is less of a problem than under-specification and it can be mitigated by labeling particular functions or blocks of code as implementation specific and not part of the spec.
Without spec written in code, the different implementations always have subtle incompatibilities. I see egregious versions of under-specification in government where horrendously vague specs are created in order to issue RFPs for getting software built. They usually end up with non working software at mind blowing cost.
People have this weird misconception that you are contracting out to build software. You are not. Building software is really easy. You press the build button or type the compile command. Building software has been fully automated for a while now. What is difficult is designing software and specifying what it must do. This is because there is a vast jungle of protocols, business flows, hardware and software platforms that need to be interacted in different ways for different needs. This is what needs to be specified and only computer code can do it adequately.
I wish that Mozilla adopted the chromium core. We really need a well funded non-profit managed release of the reference browser.