Yes, I'm aware of the problem: To create the builtin export data, one needs a working compiler. That compiler relies on reading the existing builtin data. If the export format changed, the old format (used for the builtins) cannot be read.

The problem always existed, even with the textual format, but the textual format was a bit more "elastic" in the sense that internal node changes didn't necessarily reflect themselves directly in the export data syntax. The new export format is more directly coupled to the node structure (which is why it's shorter and faster), but any node structure changes more immediately affect the export format.

The work-around (for now) is to make the importer to read both a prior and a new export format, and the exporter to produce the new (changed) export format. The importer may be told what to do with a temporary flag, or a marker in the export data (version string can be used). The so adjusted compiler can then be used to create a new builtin.go. After that step, the work-around scaffolding can be removed again.

Agreed that this is cumbersome. We probably cannot avoid the need to read both an old and a new export format in case of format changes, but it should be possible to provide some internal support to make that step easy.

Will document for now.

There's no reason the builtins have to be imported the way they are. Another option, now that the parser is a bit more sane, would be to just parse the original Go declarations that the export data is currently built from. It would require knowing that you're parsing on behalf of a different package and that "any" is a thing, but the complications should be fairly limited.

Yes, I thought about that in the beginning as it would be much simpler. But there's still some "compilation" (type-checking, if minimal) involved and I didn't want to touch more than necessary for the switch to the new format. Worthwhile considering for 1.8.

CL https://golang.org/cl/23443 mentions this issue.