Do you have a strong reason for wanting to make these changes (besides being "standard compliant")? The package is tiny, you can always make a copy and adjust it for your purposes and post elsewhere. Once we try to follow the standard, there is going to be a maintenance burden, because there will be bugs.

I'd prefer this would be left alone; as I don't see any benefit here. Specifically:

• The package already supports /* */ comments, I don't see much difference between (* *) and /* */, except that the former requires some work to get right because text/scanner doesn't support it.
• Using ";" instead of "." also seems of marginal benefit, though easy to do. But why have two different ways to do the same thing? (N. Wirth proposed EBNF originally, and he uses "." : http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf, page 11.)
• I'm not a fan of the "?" notation at all. It literally raises questions when you just see it (what does it mean?) - it's definitively not self-explanatory. Using a comment gets the same job done and the meaning is more obvious. The fact that the ? symbol means 0 or 1 times in other notations only adds to the confusion.

I was looking at how to define EBNF spec for a syntax I'm working on (https://github.com/bamarni/ticketfile), and maybe use x/exp/ebnf to validate the spec file during CI.

I reported this as it could have been an improvement and possibly a first contribution. But if you think that's not worth the effort I'll probably stick to the golang spec style.

It sounds like you are free to define the syntax however you like (i.e., the exact notation is not forced upon you through some external body). If that is indeed the case, I'd recommend that you just stick to the style used in the spec if you want to use this library.

The point of EBNF is to make syntax easy to read, and our choice may not be the standard, but it's not uncommon, simple, and it's faithful to the original intent by the inventor N. Wirth (standards have a tendency to add unnecessary complexity). Instead, focus your energy on the rest of your product (just my recommendation).

On the other hand, if you insist on following that particular standard for whatever reason, I suggest you just make a local copy. The library is really small, and then you have full control over it no matter what. In fact, this might be the best choice for you since x/exp is experimental and we're not giving any guarantees about its content or how long it might stay as is or even be around.

Finally, if you're looking for a way to contribute, there's plenty of stuff to do that's interesting, and that would have more impact (because it's more important). A starting point is to look at open issues https://github.com/golang/go/issues and see if you can find something that you'd feel comfortable to tackle (search for the "suggested" label). More urgent issues can be found by looking for the Go 1.8 and Go 1.8 Maybe labels.